In the previous article I said that your first contingency plan for running servers with the Windows Server 2003 operating system after the EOS date is to get a custom support agreement. Here are some more suggestions.
Probably foremost on you mind, even if you do have a custom support agreement, is that Windows Server 2003 has disclosed vulnerabilities, such as those mentioned in MS15-005. https://technet.microsoft.com/en-us/library/security/ms15-005.aspx. One of your contingencies in dealing with Windows Server 2003 if you aren’t able to remove it from your network should be to isolate the workloads it hosts. This means coming up with a way to limit interaction with the server to trusted hosts.
If you have Server 2003 on the perimeter network, you need to prioritize migrating that workload. What you want to do is to minimize the number of hosts that will interact with any computers running Windows Server 2003 and placement on the perimeter network isn’t exactly conducive to that goal.
How you limit which hosts can communicate with Server 2003 servers on the internal network is up to you. You could create internal protected networks on your organization’s internal network and then use firewalls to control which hosts can access the hosts on the protected internal network. You could use IPsec isolation policies to ensure that only computers with special IPsec certificates can establish communication with your organization’s remaining Server 2003 servers.
The best contingency is to have migrated away from Windows Server 2003. If you can’t do that, judiciously restrict which hosts can communicate with computers running Server 2003 until you are in a position to decommission servers running the operating system.