It’s time for the final migration.  You’ve completed a Proof of Concept and a rehearsal for the process but now you have to complete the process and move the actual production application while it remains in production. Regardless of the migration methodology you’ve chosen, if you don’t get a lump in your stomach at the start, you’ve got ice water running in your veins. I’ve heard this process compared to changing all the tires on an 18-wheeler while it is still running down the road.

 

All of the previous steps taken lead up to this event.  The initial analysis defined the scope of the migration.  The proof of concept determined what the scope really is, and defined all of the components involved in the migration.  Also, the proof of concept likely ported and proofed the components that could be rewritten or modified without impact on the production system.  The rehearsal provided a timeline for the migration, along with an estimate of the production outage that may need to occur.

 

With all this data, the application owners and those charged with the migration need to sit down and plan this final step.  Cold feet can’t stop this intrepid team. Resumes prepared and recruiters notified, the team pushes on.

 

The final step plan starts with targeting the possible outage at the most reasonable time. This is often a weekend or a late evening, depending upon how long the outage would last.  Often, holiday weekends are chosen  (I once did a migration over the fourth of July holiday).  Include in your plan for best case and worst case scenarios for the outage duration.

 

Start the migration by cleaning up the target server.  Set the BIOS to the optimal settings you determined during the POC.  Load the operating system and set the parameters. If you’re installing Linux, add any required packages and, of course, add sysstat.  Install any application systems that are required by the application you run. Tune these for the application and platform.

 

Begin the migration by setting up the application system.  If you are moving a database, you set up the database.  If you are hosting a custom application, install the source code and compile the executable.  Set up the network links for the final conversion.

 

As soon as all the preliminary tasks are done, begin the migration.  For a migration of a custom coded application, this could as simple as pointing the other applications dependent on it to the new host.  If a binary data store like a database is involved, then the migration can be a lot more complex.  But you know what to do -- you’ve found out the best method in the POC and practiced it in the migration rehearsal.

 

Once the data is moved over and the application is ready to run, if possible run the test harness against the new system.  Audit the database to be sure all the tables, indexes, procedures, views, referential integrity constraints, database links, synonyms, and other database objects are all there. Finally, the last step is opening it back up to production. Then, go get some sleep!

 

After one migration I went back to the hotel and slept hard. I’d had maybe 4 hours rest in 72 hours, and I was pretty bleary.  When I went in Monday morning, there were cars in the parking lot.

 

"Hurrah! It worked! I thought. The company wasn’t going to let any workers into the plant if the migration had failed, but here they were working.   Subsequent testing by the user team assembled by the company to proof the process showed a few glitches on Monday (and for a few more days) but those were quickly tackled by our QA team. The lesson here is that once you’re finished with the steps, you aren’t completely done. You still have to monitor the situation to ensure all is well.

 

However, the migration is now finished.  You’ve got an all new platform for the application.  The old one can be put out to pasture (but it’s probably not a good idea to use it to make a fishing reef, given all the chemicals in a computer system!)