The Key to a Successful Cloud Migration Is What Comes After
A decommission project must receive as much attention as the cloud migration project it accompanies.
- By Stan Pugsley
- December 6, 2022
Nearly every cloud migration project, or system upgrade for that matter, begins with the promise of some combination of increased functionality and deceased costs over the long term. The improved functionality may be in the form of new features, an improved user experience, or a better service-level agreement. Decreased costs may be related to lower licensing, hardware, or human resources costs.
One of the key assumptions in the calculation of return on investment is that the old, legacy systems will be successfully decommissioned. That is where projects can fail to accomplish their stated objective. The decommissioning step is often the most complex and most important part of any upgrade or migration.
The value of decommissioning is obvious in most other parts of our lives. If you rent a new apartment, you would like to end your lease on the old apartment as soon as possible to avoid paying double rent. If you buy a new home, the goal is to sell or rent out your previous home as soon as possible to avoid a double mortgage payment each month. In each case, it might be convenient to use your old apartment or home as a storage area or to let a relative stay there for a few nights, but the extra costs will keep accruing, reminding you to part with the old.
In addition to hard, visible costs, we need to consider the soft, invisible costs of failing to fully migrate to a new system. If you buy a new laptop but feel too attached to your old laptop to fully turn it off, you are increasing complexity, confusion, and duplication in your work (and life). Legacy systems present an alternative set of data that may conflict with the corresponding data in the new cloud system. You may create confusion among users and developers who are constantly required to decide which system to access. Maintaining two parallel systems in perpetuity will create extra risk, confusion, and effort in every business process.
The following two graphics show the effect on total costs depending on whether full decommissioning is achieved or neglected. In the first example, we assume that the new data platform is brought online as a pilot project and then brought into production in parallel to the legacy systems. The costs and complexity of the environment increase with the new environment and never decrease.
The cloud maturity levels indicate the location of the system of record but don’t necessarily specify that old, legacy, on-premises systems have been fully disabled. Reaching maturity without cleaning up the legacy systems is a very expensive route.
In the second scenario, a significant amount of effort is made to decommission the legacy systems and the costs decrease to the projected level over time.
Decommissioning is the crucial difference between those two scenarios, yet it is often neglected or underfunded.
What makes decommissioning so difficult is that it must be 100 percent completed to receive any cost savings. For example, a database with even one remaining user, application, or interface must be kept online, supported, licensed, and managed. Unless that single remaining connection is migrated to a new home, none of the cost savings can be achieved.
Additionally, your decommissioning efforts will be fighting against data gravity, asking teams to contribute time and resources to an effort that may appear to be low priority or even against their interests. Unless you have strong executive sponsorship and have created a clear business case for the migration, you may find that some departments will happily opt out and remain on the legacy system. Your goal is to send a clear message that the migration and shutdown of the old system is going to happen and there is no alternative but to get aligned with the timeline.
We can look at the decommission process as a six-step journey -- from informing to serving final notice to evicting any last tenants.
As with any process, what gets measured gets attention. The decommission process should have its own project plan with clear steps (as listed above), owners, and deadlines. An inventory of all affected systems can help create a checklist to use for the project plan. If a particular system integration is behind schedule, then management attention and resources can be brought in to help. As the project progresses, you will need to make sure that communication, technical support, and financial support are applied in equal measure to push all the migration threads to completion.
You wouldn’t buy a new home without thinking about the fate of your current home. You wouldn’t buy a new car without a plan for your old car. In the same way, you shouldn’t embark on a cloud migration without planning to bring every user, report, application, and data integration involved along on the journey. By planning your decommission with attention equal to the migration, you can achieve the expected cost savings and simplify your environment for the long term.
About the Author
Stan Pugsley is an independent data warehouse and analytics consultant based in Salt Lake City, UT. He is also an Assistant Professor of Information Systems at the University of Utah Eccles School of Business. You can reach the author via email.