In this last part of my system migration discussion, I want to discuss when your trading partner or one of your service providers migrates their system. In my previous post, I talked about making a change so that anyone connecting to you would not have to make any changes. Or even know that a change has been made. Your trading partner, or service provider, could decide to go that route, but they probably won’t. They will probably go out of their way to make their change as painful for you as possible.
Some of the things you need to consider
If one of your integration partners reaches out to you informing you they are doing a system migration, I want to make sure that you don’t take anything for granted. Don’t assume that anything will remain the same as they currently are. Some of the things you need to think about are:
- File naming conventions – If you have logic built into your processing where you are dependent on how the files are named, ensure that you validate that the file names will remain the same. If anything changes, you will need enough lead time to make any process changes and test the changes before the production switchover.
- The direction of data flow – If you are pushing files to your trading partner’s server, or they are pulling files from your server, validate that this will continue to be the case.
- Whitelisting – If you must white list your trading partner’s IP before you allow them onto your network, make sure you get the info for their new server(s), so they can continue to connect to you. If they have both a test server and a production server, make sure you get the info for both of them. If they have a separate server (or IP) for disaster recovery, make sure you get that as well.
- Scheduled downtime – If you currently have rules around when you can connect to their server (their server is always down over the weekends due to maintenance, for example), make sure that doesn’t change. Or if it does, make sure you get that info so you can adjust things on your side accordingly.
- Directory structures – If you connect to their server and push files to them, make sure the location you are currently sending to will remain the same. Likewise, if you connect to their server to pull files, make sure they will be in the same place for you to retrieve.
- Timelines – Make sure you have a clear understanding of when things will happen, both on the test side and the production side. Also, make sure you know exactly what is expected of you. You will need to be able to plan for these changes and manage all of the other projects and timelines you are involved with.
- Credentials – If your trading partner connects to you, they probably won’t have the password for their account (or accounts) they are using. You will need to be able to provide the password(s) to them. If you can’t do that, a likely scenario, then you will need to reset the password(s) and coordinate the change with them.
Test Test Test
I can’t understand why people think things like this don’t need to be thoroughly tested. But I see it on almost a daily basis. Basic connectivity needs to be checked out. You need to make sure that you have permission to create, read, and delete files on your trading partner’s server (if those things are part of your current process).
There should not be any changes to the file formats, but this is still something that needs to be tested out. If your trading partner switches from a Linux-based server to a Windows-based one (or vice-versa), the formatting could get changed, especially the end-of-line characters.
I recommend that you test at least one of every file type you exchange with your trading partner. If there is a request/acknowledgment process flow, I would make sure the whole process gets tested. It is important that you can not only send files back and forth but that you can successfully process the files once you have them.
Monitor closely the first couple of days
Once the production switch-over has taken place, you want to pay close attention to the traffic you are exchanging with your trading partner. You may not expect to see all of the different file types on the first day. An invoice file or a remittance file may only be sent at the beginning or the very ending of each month. You want to ensure that all of your file types are being exchanged just as they were before the migration and that all of the different file types are still processing as they should.
I know that you would have already tested everything thoroughly and that you have monitors set up on your system to alert you to any issues. Still, it is worth the extra effort to ensure everything is flowing on the new system like it was on the previous system.
A system migration, especially if it is your system, can be a stressful experience. There are a lot of things that need to be considered, and a lot of things being put on the line. Not just business, but also reputations. But if you take the time to think things through, and plan thoroughly, it will hopefully make things go smooth. And if everything does go South, for whatever reason, make sure your plan includes a way of switching back to the original system easily.
As I stated when I started this series, anyone that has been working with technology for any period of time has probably experienced a system migration. I would be interested to hear what your experience has been. And what solutions you have come up with that we can all learn from. Leave your comments below.