Today, enterprises that remain complacent are rewarded with bitter shortfalls and an endless cycle of playing catch-up. Moving from legacy technologies to more agile and cost-effective solutions is an important part of any enterprise's metamorphosis; however, it can be riddled with pitfalls for the unprepared.

According to a study conducted by Boston Consulting Group, which surveyed 825 senior executives at 70 companies that were undergoing 895 digital transformations, only 30% of the transformations achieved their goals.

Those aren't numbers that inspire confidence. Fortunately, companies like Stark & Wayne have worked to make multiple enterprise migrations possible, so others can avoid the pitfalls. Stark & Wayne is an expert in migrating enterprise infrastructure. Past projects have included Cloud Foundry Foundation deployments managing 45 000 application instances.

Document your performance baseline

It's a mandate! Every company demands improved performance, but many lack baseline performance metrics or ways to measure what better performance means. Is performance tied to the end-user experience? Is it based on scaling workloads up and down to reduce consumption? Is it measured by reducing deployment or upgrade time? Once you define how you'll measure performance, you can connect it to your applications, customers, and business.

This will allow you to assess whether applications are performing inefficiently during and after migration. It also helps manage perceptions during significant changes and quantify success. You'll need to compare your platforms before and after migration using similar workloads.

What you measure depends on business requirements, but there are some common ones.

List of standard checkpoints

  • Component uptime
  • Application response time
  • Total application execution time
  • Test applications to check component connectivity and service availability
  • API metrics (page load, memory usage, CPU, server performance)
  • Log output load
  • Incident report load over time
  • Automation (and treat automation as a first-class citizen, because it will improve overall performance)
  • Changes in operating expenses due to migration and task automation
  • Test application types that model your environment.
  • Good dashboards: you can't migrate what you can't find

Most organizations know what they're supporting now, but they need to determine what they want to support after migration. Finding the number of application instances isn't difficult, since your provider will likely bill you based on that metric. Still, you also need to know the number of applications, which groups support them, which applications are interdependent, and what types of services each application consumes. Identifying these variables will help determine how you can migrate and support the new environment.

When identifying the owners of each application, it's important to determine which of them have automated test scenarios to verify that the application is working. Ideally, every application should have automated test scenarios, but at the very least, you need to map the application owners. In addition, you'll need to look for unused and unsupported applications.

The last thing you want to do is migrate a nonfunctional application (we've seen it happen) when it needs to be removed or fixed before migration. Surprisingly often, you'll find that no master mapping of application owners exists, which causes problems during and after migration.

So the focus is on “inventory, inventory, and more inventory,” because many companies don't have a centralized catalog that lists who owns each application, what each application has or does, and what impact it has on the business. Being able to quickly query and find the information you need is vital for operations, efficiency, and business decision-making.

Where do you start? First, answer some general questions:

  • Which regions do you operate in, and why?
  • Which applications run in each region?
  • Which services does each application use in each region?
  • Which version of Linux is being used?
  • Which applications interact with other applications in the region?
  • Which applications are customer-facing, and which are internal?

Collecting these initial data points won't answer every unknown, but they'll start to give you the information you need.

Test what you can: and accept the unknowable

No matter how thoroughly you test or document every detail, there will be unknown variables that affect downtime, customers, and collaboration.