Getty Images/iStockphoto
5 tips for creating an IT ops application migration plan
Migrating applications can be complex, especially for IT teams dealing with sprawling legacy systems, but devoting time to planning and testing can avoid hassles down the road.
Moving applications, changing software vendors and migrating IT infrastructure are delicate, time-consuming and complex tasks that must be done correctly to avoid downtime and other issues.
Take Broadcom's acquisition of VMware as an example. VMware offers much more than a hypervisor, including self-service IT ops tools such as the vRealize Operations platform and the NSX virtual networking and security platform. After Broadcom announced its acquisition of VMware, anxious VMware customers began to consider alternate platforms, but moving such deeply ingrained infrastructure has challenges.
Over time -- decades, in some cases -- dependent services and tooling become extremely intertwined, and environments grow highly customized. And it's not just VMware that presents such problems; it's any sufficiently complex core application or system. IT ops teams building an application migration plan should carefully consider the following factors.
1. Understanding and documenting dependencies is key
For modern applications, complexity runs deep. Hopefully, so does the documentation.
Over time, the dependencies for any platform grow. But they might not always be properly documented in the appropriate places. If application documentation doesn't yet exist, creating it from scratch is an essential step to success.
Moving an application en masse and then realizing it doesn't work is a shortcut to misery, because it could be incredibly difficult to revert to the previous state. Documenting known dependencies and breaking them up into smaller, manageable chunks is key to a successful migration.
2. Don't try to recycle items from the old environment
Reusing resources does a disservice to yourself and the company, since IT teams risk losing the ability to failback in a worst-case scenario. What's more, if the organization misses certain legacy items, key elements of the infrastructure could go down at the worst possible time.
Attempting to reuse old infrastructure is false economy, as outdated infrastructure is typically less efficient and less reliable. While new technology has a serious upfront cost, adopting it can save money in the long run.
3. Big-bang moves usually end badly
Any migration plan worth its salt should break down a project into a set of well-defined and well-understood deliverables. The more moving parts a system has, the greater the potential for failure. Reduce this risk with proper planning and smaller, self-contained changes.
This preserves the ability to revert to a working configuration should there be an insurmountable issue -- an option that should never be underestimated. Remember, downtime equates to lost income and idle resources. Ensure any plan includes ways to revert back where possible, and have a known-good, tested backup ready to go, just in case.
For application migration plans, in conjunction with the previous points, breaking the migration down into testable parts is key. With a new environment, there can be plenty of dry runs before the cutover or real migration, which can highlight issues before they break the new production environment.
4. Professional services can simplify large-scale migrations
Perhaps a bit controversially, vendor professional services can be extremely useful for larger migrations when it comes to planning. It's the job of the vendor's IT team to understand the pitfalls, workarounds and optimizations for a given product because they work with it day in and day out.
Depending on the size of the engagement and other variables, professional services can be reasonably priced. Although there is an upfront cost, the optimizations they can provide mean the time to payback can be short.
5. Don't try to do too much
Stick with like-for-like migrations as much as possible. For example, trying to import a data set from a previous version of a system to a brand-new instance can cause issues due to factors such as new data formats and different table layouts. Keeping things simple and using the same versions where possible is good advice learned the hard way.
Large migrations require extensive research, design and testing. Plan, test and then test again before the real migration. Developing an application migration plan is a necessary step to a modern, responsive environment -- and the costs of rushing and cutting corners can be huge compared with taking the time to do things right.
