When you are migrating your system, and your actual host server will change, you have a couple of options:
- You want your trading partners to make a change to connect to your new host.
- You don’t want any of your trading partners to make any changes.
You want your trading partner to connect to your new server
Having your trading partner connect to your new server is the easiest path to follow, and it doesn’t put too heavy of a burden on them. They simply need to change the host name on their end to connect to your new server. You need to make sure that their credentials are the same as the old server. Their directory structure should be identical to the old server, as well as the permissions to the directories and files underneath them. So basically, from their perspective, nothing changes other than the host. Your job is to make sure everything behind the scenes operates the same as your old system did.
White Listing
If you connect to your trading partner’s server to push data to them, you need to know if they require your host to be “white listed” to be allowed on their network and make a connection to their server. If so, you need to make sure they have the info they need to update their white list, so your new server can continue to push files to them.
You want to be completely transparent to your trading partner
If you decide to go the other route and be utterly transparent to your trading partner, they would not even have to change the host they are connecting to. The way you would accomplish this would be to create routing rules within your network. When someone arrives at your external firewall asking to connect to your old server, they will be automatically redirected to your new server.
White Listing
As above, if your trading partner requires your host to be white listed before you can make a connection to their server, you must be sure that you are presenting the same IP and host name as your old server, so these connections can continue to take place.
Network Upgrades
There will come a time when you, or your organization, will need to make changes to your network. Any routing rules created during this process must not be lost when that happens.
If any of your trading partners are making changes on their end, and they reach out to you to help them test, you can take the opportunity to ask them to change to connect to your new host directly. If they ask you for help, and they are making changes anyway, they will more than likely agree to make the change. This would be one less customer you need to worry about if routing rules were ever corrupted or disappear. Any new customers, of course, you would have come directly into your new server.
Testing Considerations
- External traffic – You want to test transferring files to your new server external from your network. Ideally, you will get some of your trading partners to test with you. This can be problematic because they have their own projects they are working on, with their own timelines.
- Internal traffic – You want to make sure that you transfer any files, from either direction, with any servers internal to your organization. You need to be just as careful with these transfers as you do with your trading partners.
- Load testing – You want to make sure that your new server’s performance and processes are at least as responsive as your old server. You don’t want to find any bottlenecks once running in production.
- Data sets – You may be in a situation where you cannot process production data on your test systems. If that is the case, you need to have test data sets available to you to use for all of your testing. Not all of your trading partners may have the same constraints. If that is the case, and you need such a partner to test with you, you may need to provide them with test data that they can send to you. I know this sounds crazy, but I have found myself in the situation before.
- Keys – Any PGP encryption/decryption needs to be tested to ensure everything works as it did on your old host. Any connections you make using SSH keys (instead of passwords) need testing. You also need to make sure these keys are copied over as part of your system migration.
Other Things To Consider
- Monitoring – Hopefully, you have monitors set up checking the health of your system. These should include checking for files that are not being moved as they should and checking that your host is reachable. These will need to be updated to monitor your new host.
- User accounts – If user accounts need to be migrated, you should hopefully have a tool to help you with this. Getting a list of usernames should not be difficult, but obtaining passwords could be. And you don’t want to ask your customers what their passwords are. You should have a way to migrate your user’s credentials from one system to the other. User accounts are probably one of the first things you should plan for but will be one of the last things to do as part of your migration. You want to make sure you capture all of your active users, so there will be no disruption once they land on your new system. Depending on how often new users are created or how frequently people are changing their credentials, you may need to place a moratorium on building new accounts. You would want to make this as small of a time as practical.
- Big bang or a few customers at a time – This is another thing you want to consider and decide on at the very beginning. Doing a few customers at a time reduces your risk. Maintaining two systems, however, introduces its own risks. Making sure the functionality is synced is one thing to consider. If you are using a third-party product, you may need to maintain two licenses for a while.
These are just a few of the things you need to consider when migrating your system. I’m sure there are many other things you will run across when laying out your plan.
In the next post, I will discuss things to consider when one of your customers or service providers is migrating their system.