Completing a migration, whether it’s for version-to-version migration or for platform updates or even moving to a cloud-based solution from an on-premises solution, is a major project. Even a sideways version swap, accompanied by a platform change can mean all sorts of things in terms of settings, features, capabilities that may have to be modified, for sure have to be tested and may require workarounds.
The steps to update have so many variables. One of the biggest trends that is very apparent as you work with these is the fact that so many tools and platforms and touch your SQL Server. Many that you may only be aware of in a passing way but that have to be considered as you set up your migration plan.
One of the best first steps you can do once the decision has been made to proceed with a migration is an inventory. It’s one thing to log the applications and systems that you know about – that’s, of course, something you want to do. But you should also take some time and monitoring effort to find out what sporadic access is happening. This could be big things like applications or IoT solutions, or even the super-secret, attaches only once a month spreadsheet that that superuser in accounting uses to summarize business happenings… Finding out what those access points are will be critical to the success of your migration.
This initial step, that of inventory, is one of the most important as it will scope your efforts and also set up your work so you know when you’re done – what does “success” mean when you’re all set at the end of this project? This is, perhaps, one of the steps that makes me the most nervous to get right with the way so many tools and technologies have intermittent or sporadic access.
The next step sort of harkens back to some of the advice I’ve seen for application development. “Begin with the end in mind.” In other words, know what success looks like, and know how to test for it. So many times people go roaring down the update path, doing their moves, the conversions and all of that. But you simply must know how to test for success in each of the applications you’re moving over in the conversion. Do the data inserts/updates happen as needed? Do the reports work correctly? What is “correctly?”
That last question is important. How will you know that report is pulling information correctly? I’ve seen people insert a new bit of information in a table as a way of confirming conversion and connectivity. I’ve seen reports that run before, and after a conversion – and then are compared. User access, testing, updates, insertion of new information, other devices and their access points.
These all come together to help validate connectivity to the new system, help confirm functionality, and make sure things are updated as needed. Then, once you have the inventory of work to be done, and how you’ll know success (or failure), you can get started on next steps.
