Nine best practices for a successful migration
Anyone who’s done migrations probably has a list of dos and don’ts to ensure their migration projects are successful. Our team in IBM Systems Lab Services Migration Factory is no different, and in this final post in the top application and system migration worries blog series, I’d like to share a few best practices we’ve developed and refined over 30 years of doing migrations.
Migration best practices
1. Assessments aren’t optional.
Assessments are the backbone of any migration project. Without them, you’re basically flying blind.
2. Involve the client’s business as soon as possible.
It’s crucial to make sure all the relevant business units are involved in planning the migration and aware of how it could impact them. Clear communication up front paves the way for a successful migration.
3. Never modify the source database.
In Lab Services Migration Factory, we always use copies for our test (mock) migrations. During the go-live weekend, we shut down the production databases and begin the cutover process. If a problem arises, we simply stop the migration and restart the production database on the source system. This gives the client confidence that a back-out plan will work if needed.
4. Isolate the migration from the client’s day-to-day operations.
Use staging servers wherever possible so you can avoid an outage on production systems. This also helps eliminate the possibility of the migration bringing down your business. Note that the staging servers need to be as close as possible to the configuration of the production servers so you can establish accurate timings for the cutover.
5. Understand the complete application stack.
A request to migrate a Java or C/C++ application with 500K lines of code is only part of the solution. It’s important to fully analyze the complete application stack to understand what else will need to be migrated to ensure that the code will work on the new platform. For example, most Java applications require a server like IBM WebSphere Application Platform, and C/C++ applications can use Tuxedo to host the programs.
6. Correctness first, optimization second.
When companies do migrations, they expect their applications to run faster on the new system…and they usually do because the technology on the new platform is generally faster than the older platform. However, migrating for correctness should be the number one goal in any migration, before focusing on optimization. There’s no point optimizing code that doesn’t produce the right answer.
7. Don’t combine an upgrade to an ISV application with a migration.
Aside from database migrations and SAP’s DMO (database migration option), it’s generally not a good idea to combine an upgrade to an ISV application along with the migration. It’s better to either upgrade the application on the current source platform and then migrate or migrate first and then upgrade. Many clients prefer the latter as the new target platform is always faster than the older source.
8. Don’t migrate applications under development unless you have a very good code synchronization process.
Most custom code migrations occur while the source is under some form of development or active maintenance, which is why having a “code-synch” process is essential. The “frozen” version of the code is used to create a baseline source system for that version on the new target platform. Once that baseline is migrated and tested, you can apply the body of code changes to the migrated code base.
9. Test. Test. Test.
Without a proper test plan, you won’t have a successful migration. We begin talking about how the migration will be tested on day one of the assessment. If you don’t have a test plan, IBM can help you create one.
Summary and closing
We’ve covered a lot of ground in this series, and I hope you’ve found it helpful. For a full list of my migration blog posts, click here.
And if you’re looking for help with a migration project, contact Lab Services Migration Factory today.
For technical practitioners interested in learning more about IBM platforms and services, I recommend attending the upcoming IBM Systems Technical University (TechU) in Orlando, Florida, from April 30 through May 4. TechU is the place to get deep technical training on IBM Systems platforms and technologies.
*I received a lot of very positive comments and am gratified to know that many of you found this series informative and useful. I want to thank several of my colleagues who’ve taken the time to look at early drafts and provide comments, which I know made them a better read. So thank you Walter Camp, Marty Carangelo, Niki von Dehn, Kevin Galloway, Rick Murphy and Mark Short.
