Morning came secretly, dreary and cold. The overcast that would last all day could not be seen inside the data center. The previous 16 hours were brutal and contentious. One by one, each application was migrated to the new data center and the team finally caged the remaining application beast. And now they wait for the end users to wake and, in some cases, panic.
The complexity and struggles of an application migration are known only to a few. In this age of downloading an application to a smart phone and configuring it with a few taps, the idea that migrating software applications from one datacenter to the cloud could be difficult is inconceivable. Most executives see the task as a simple step – move the application from the origin to the destination. Of course they want no downtime and no cost to the organization and no change in behavior when the application roars in its new home. A utopian dream of seamless, costless, and well-behaved migrations. A dream that rarely comes true.
Nearly everyone believes that perfect planning is the key ingredient to any successful project. In fact, most project management training orbits around this tenant. The manifestation of this orbit is a detailed Microsoft Project Plan document, complete with sub-categories, due-dates, dependency mapping, skill tracking, and the mandatory Gantt chart. This explains why I get daily requests for a sample migration plan that can be copied and modified. Everyone loves a shortcut!
The obvious truth about application migrations is that although they are complicated, executive indifference often means underfunding and underestimating the impact of this messy endeavor. What are some other factors that make migrations challenging?
Many technical professionals have no idea how to move the applications they manage.
When pressed by their project manager (who may also be new) to enumerate the steps, they really do the best they can. Critical details are missed and dependent complexities are dismissed in the desire to get a plan to paper. It’s not their fault that they don’t know the migration recipe. After all, they didn’t write the applications and no information is typically kept about the services, configuration, and data that applications require to function. Remarkably, the expectation is that these technical professionals are the beast tamers required to move those applications from the origin to the destination. The premise simply isn’t credible but the entire plan is based on this false hope. Even worse, is that the entire blame for failure falls to the technical team attempting the task. Executives rarely admit they underfunded and oversimplified the endeavor.
Most applications have been running for a very long time and might predate most of the current staff.
You inherited these beasts. You likely didn’t install them or go through the initial training and configuration steps. You merely feed them daily to keep them running and keep the organization happy. Often, software maintenance was cut in order to save costs so that even the software vendor is now inaccessible. Years of lifecycle neglect for applications are common. No changes are made to hardware, operating systems, and software configurations out of fear of breaking an application. These outdated dependencies are kept in place despite the inefficiency or the massive resources being consumed.
What does that mean for their migration? Of course you should correct the lifecycle neglect of these applications prior to moving them. Most will not for schedule and budget reasons. And that reality foreshadows a brutal application migration.
The true subject matter experts for any application are the creators.
The reality is that few of you will involve those creators. In some cases, you can’t involve them even if you wanted to (especially if you aren’t current on the software maintenance.) Therefore, you will have a gap in knowledge with unknown risk in your plan. Plan reviewers won’t know which applications have just a superficial understanding applied to them. Your plan might look impressive and yet still be deficient.
Many fear losing their jobs if the migration goes badly.
While it may seem like an irrational fear, it’s actually a legitimate concern. After all, you have executives indifferent to the complexities who underfund the entire effort coupled with staff unfamiliarity with the rouge applications. What can go right in this climate?
Avoiding responsibility is the common tactic in this environment. It leads to many of the common reasons for failure including lack of urgency, failure to speak truth to power, and burning the runway with endless meetings with no concrete outcomes.
A merger or acquisition forces an inherited timeline and bloated expectations.
Just because a deal captain promises synergy and immediate accretive benefits doesn’t mean you can overcome the lifecycle neglect, the underfunding, and the lack of diligence in the underlying technology stacks being merged to meet the deadlines and the unreasonable expectations. It just means you’ll have a hasty plan operated in a crisis environment with inherited but infeasible deadlines. Hostile executive oversight emerges because their promises are now at risk. They aren’t going to admit those promises were made based on incomplete technical diligence. In many cases that diligence is purposely avoided out of fear that knowledge kills deals. This environment intensifies the flight risk danger because the technical team needed to prosecute the migration is likely the very team being targeted for synergistic reductions in force.
Rescue swimmers are an expensive way to save your application migration.
Simple prescriptions to complex problems can easily be found online. After those prescriptions fail, then what? A frantic SOS (save our ship) for rescue swimmers to save the migration project? Like a Coast Guard rescue, those kinds of rescues are expensive. That’s the reality of most projects. Preaching about what should have been done instead won’t save the migration.
Blaine Berger is a rescue swimmer for data center migrations. His book and checklist jump start first time practitioners with actionable advice. If you want to avoid a rescue swim, consider having your migration plan peer reviewed by Blaine. You can connect with Blaine on LinkedIn or via e-mail: blaine@e-oasis.com