When It Comes To Migration, Context Matters
By Matt Brown
Business context is a critical element to a migration that is not only successful for IT but also the business
While enterprise transformation and migration projects may be IT driven, the truth is that they should be business focused rather than IT focused. Sure, there are numerous advantages to IT for proceeding with the project: simplified operations, obsolescence remediation, increased security, enhanced resiliency, and the list goes one and on, but all of these are necessary to provide a better service to your business. Therefore, gathering the right context to make the project a “non-event” for your business is critical.
There are no shortage of tools that tout electronic migration planning. Those tools do a really good job of discovering the environment, learning communication patterns between instances, and suggesting potential migration groups. The primary issue with these groupings is that the tool’s default assumption, because it doesn’t collect context, is that the workload or service will be migrated as is, which is typically not the most appropriate method (especially if going to public cloud).
Electronic discovery is absolutely critical, but even more so is understanding the context behind the assets, applications, and services. There are a myriad of migration methods that can be used to transform and/or migrate applications and services. However, gaining context will help an organization choose the method that is most appropriate for their program requirements.
Imagine that you want to go fishing. Your boat and fishing poles packed up and ready for a day on the water. Now you’ve made it to the lake, launched the boat, parked the truck, and are ready to find the first fishing hole of the day. But you were in a hurry and didn’t take the extra 10 minutes to review the fishing report or check the weather forecast. So now you’re not sure where the best place is to fish and have no clue what they’re biting right now. Should I use lures or bait? Does it change based on water depth and temperature? Oh crap, I didn’t get any live bait, so I reckon I won’t be using that. Great, now it’s starting to rain. Did I just hear thunder? Or it could be a beautiful day, but the wind is whipping at +20mph across the lake. Now you can’t keep your boat anchored, the wind is making it impossible to make an accurate cast, and the constant rocking of the 3’ waves is starting to get dangerous. But you muscled through all of the elements and hooked into a fish…and it’s a whopper! Fantastic, FISH ON!!! But you forgot your dip net and as you try to get it out of the water, the fish makes one last desperate leap, the line loses tension, and the fish shakes the hook out. That’s a lot like trying to execute a migration or transformation without collecting context information. Understanding the supporting details goes a long way to increase chances of success, reduce issues, and make the overall experience more enjoyable for everyone involved.
All clients and transformation/migration projects are unique. So the context gathering elements will need to be customized for each situation. However, there are a few elements that are staples for this activity and cannot be gathered electronically:
-
Vendor support requirements
-
External connectivity
-
Cyclical tendencies and dependencies
-
Application life cycle
-
Current constraints
-
Firewall, Load Balancer, and Security policy
requirements
-
Outage windows or freeze periods
-
Shutdown, Startup, and validation procedures
As a migration consultant for over a decade I’ve performed and managed hundreds of migration executions. One of the most gratifying unintended compliments that a migration consultant can ever hear, is when the project is underway or near completion, and a business executive asks, “when is that migration project going to start?”. That’s a sign that you’ve done a great job of gathering context, understanding the client’s business, and aligning that context to the technology parameters of the project.
