Common Mistakes to Avoid When Migrating

For enterprises being able to migrate thousands of applications is an inevitable part of staying competitive. Figuring out how to achieve a successful migration is scary so let’s dive into the pitfalls to avoid.

COVID-19 has created both a technical talent shortage combined with an increase in demand for accelerated technical timelines. Many companies are starting to face a “Red Queen” effect, where companies are having to re-define how and where they are competing in the market to ensure they remain relevant. Today businesses that remain complacent are rewarded with a biting disadvantage and a perpetual catchup cycle. Migrations from incumbent technologies to more responsive and cost-effective solutions are a significant part of any enterprise’s metamorphosis; however, it can be fraught with pitfalls for the unprepared.

According to a study by Boston Consulting Group in 2020, which included 825 senior executives across 70 companies involving 895 digital transformations, only 30% of transformations met their transformation targets.

Those aren’t numbers to inspire confidence. Fortunately, businesses like Stark & Wayne have worked to enable multiple enterprise migrations so others can avoid them. Stark & Wayne is an expert in migrating enterprise-scale infrastructures. Past projects have included Cloud Foundry Foundation deployments that manage 45,000 app instances.

Document a Performance Baseline

It’s a mandate! Every company demands better performance but many lack baseline performance metrics or ways to measure what better performance means. Is performance related to end-user experience? Is performance based on scaling up and scaling down workloads to reduce consumption? Is performance measured in reduced time to deploy or upgrade? Once you establish how you will measure performance, you can tie it to your applications, customers, and business.

This will enable you to assess whether apps are underperforming during and after the migration. It also helps manage perceptions during a significant change and helps quantify the success. You will need to compare your pre- and post-migration platforms with similar workloads. What you measure depends on business requirements, but some generic measurements are:

• Component running times
• Application response times
• Application overall execution times
• Test applications to validate component connectivity and services accessibility
• API Metrics (page load, memory utilization, CPU, server performance)
• Log output load
• Incidence reporting load over time
• Automation (and treat automation as a first-class citizen because it will improve overall performance)
• Operational cost changes due to the migration and task automation
• Test with application types that model your environment.

Good Dashboards: You Can’t Migrate What You Can’t Find

Most organizations know what they are supporting now but need to identify what they want to support after migration. Knowing the number of application instances is easy since your vendor is likely billing you based on this metric. Still, you will also need to know the number of applications, what teams support the applications, what the applications have interdependencies, and what types of services each application is consuming. Identifying these variables will help determine how you can both migrate and support the new environment.

While mapping out owners of each application, it is essential to identify which ones have automated test scripts to validate the application is working. Ideally, every application has automated test scripts, but at the very least, you need to have a mapping of application owners. Also, you will need to look for unused and unmaintained applications. The last thing you want to do is migrate a non-functional application (we have seen this happen) when the app needs removing or fixing before migration. A surprising number of times, you will find that a master mapping of application owners does not exist, raising issues during and post-migration.

So, the focus is “inventory, inventory, inventory” as many companies do not have a central place that catalogs who owns each application, what each application has or does, and what the application’s business impact is. The ability to quickly query and find relevant information is vital for operations, efficiency, and business decision-making.

Where to start?  First, answer the broader questions:

• What regions are you running in and why?
• What applications are running in each region?
• What services are each application using in each region?
• What version of Linux is in use?
• What applications communicate to other applications in a region?
• What applications are client-facing vs. internal?

Gathering these starting data points will not answer all the unknowns, but they will start to provide the insights you need.

Audit What You Can: And Accept the Unknowables

No matter how well you audit or document each detail, there will be unknown variables that impact downtime, customers, coworkers, expenses, and timeline. These unknowns can only be found when the technical team gets their hands dirty with the migration process. Here is how you can support them:

• Add a timeline for unknowns
• Have more resources available to help when an unknown item creates a problem
• Be flexible with company policies, internal meetings, and new feature rollouts
• Have backup plans in place such as rollbacks if tests fail
• Focus on the small wins first to gain momentum while planning the big ones. Remember, tangible quick wins can help morale as long as it does not cause more operational overhead.

The preferred method is to undertake a complete audit and document the organizational structures and relationships and use this for reference throughout the work. Once the project commences, this documentation will become your map and help avoid de-prioritizing or putting items on hold. You may find that escalation to upper management may be required to prioritize actions that you need to push through. Still, the preference should be to understand how individual teams work and establish good communication with them rather than going over their heads.

Security: Take the SecOps Team out to Lunch

We don’t mean this in the Tony Soprano “Take them for a ride” kind of way; we really mean taking the security team out for lunch to establish face-to-face rapport. The security team is vital for the migration process to constrict, loosen, or provide workarounds for blockers that arise. You also need their expeditious review of any new software required to make your migration a success. A security team that goes neglected will be a blocker. Let’s face it with another terrible movie analogy security never wants to be the Black Knight from Monty Python screaming, “None shall pass!” but they really want to serve the vital role of keeping everything safe. In the end, security wants to enable everybody within the organization as long as there are proper guidelines. If you involve them early, you will avoid headaches when security is pulled in at the last minute.

Resist Scope Creep: That’s a Really Great Idea… for Next Year

Scope creep needs to be managed carefully. All organizations want to solve their problems simultaneously, but you should be laser-focused on solving one very specific problem. Taking moving from Pivotal Cloud to open source Cloud Foundry as an example, the key strengths of Cloud Foundry are the many features that can be added and the potential for customization. For instance, improving disaster recovery posture and backups can be tempting, but creating additional scope creates additional pain points.

Scope creep also creates an issue where something can break, and you cannot be sure whether the breakage was caused by your overarching project goal or the additional scope.

Mirroring: Matching the World You Want to Leave Behind

Once you’ve established the parameters for your project and the desired outcomes, you must ensure that you have mirrored all the environments that will be migrated. This includes your operations environment or “playground,” where you will prove out everything before, moving to non-production, and finally, production.

When building out the playground environment, you will want to ensure that the incumbent technology, in our example Pivotal, is like-for-like with your non-production environment. This will enable you to be more confident that you will run into fewer issues.

Management Matters: Make Friends in High Places

You will need support from management, so do not paint an entirely rosy picture. Migrations have a long road in front of them. Moving the platform is one thing, but you have to deal with all the services as well. Management needs to know your approach to the migration and your plan to mitigate business risk. Management will be nervous since migrations could affect the bottom line, so you need to discuss all your measures to avoid that.

Failing Well: Making It a Success

Failure is good, failure is great, and failure should be expected as long as you implement lessons learned the next time. You cannot account for everything, and perceived failures happen when the unknowns become a blocker. Letting management know there will be failures will hopefully avoid the negative connotations and improve overall morale. In fact, you need to celebrate the learnings from failure because you are making progress. To sell that failure is acceptable, you need a clear fallback plan. Have this as part of your migration day planning with go/no go decision points for rolling back.

Licensing fees and risk are the main drivers for migrating to Open Source Cloud Foundry or Kubernetes. For large organizations running thousands of apps, the stakes are mission-critical. With the increasing demand for scale and developer shortages, migrations seem risky. The primary concern is avoiding impact on application teams and avoiding downtime. The good news is that Stark & Wayne has performed many successful enterprise-scale migrations that adhered to minimal developer impact and downtimes confined to change control windows.

By factoring out these common mistakes we’ve encountered, your next project is less likely to become part of that 70% that Boston Consulting Group suggests don’t get what they expect.

Also published here.