Build an Application Database for Cloud Migrations

You’ve already committed to a cloud-first strategy, but where do you start? Governance and Landing Zone design is important; however, all too often organizations can get stuck in analysis-paralysis for months and years, without moving a single workload.

We must build inertia. But how?

Finding the low-hanging-fruit applications to target in your first migration wave is key to building momentum for your cloud team. Showing initial progress to your organization while delivering tangible results against your business case is always the best way to build further buy-in. As the Italians say: “Victory has 100 fathers.”

Where to begin?

In order to achieve this early success, we need to assemble a database of applications for analysis, ranking and building a tangible migration plan based on data, not guesswork.

Here we present the 5 steps necessary to build a database of your applications, databases and servers:

1. List your applications

Getting a list of applications together to define your scope can seem like a daunting first step, but fear not! You can use a layered approach to discovery and assemble your application portfolio by combining many different data sources that you do have available to you.

For starters, if you have any existing application inventory data available, use that as your starting point, even if it only covers a part of your organization’s footprint. Then, combine it with extracts from CMDBs, spreadsheets and other operational systems that you may have. Your initial data should have: Application Name, Description, Business Units served and URLs… at a minimum. Any other data points are a bonus.

With this initial dataset, we can start to do some application discovery to fill in any gaps. One example of application discovery is mining your DNS configuration for application endpoints that aren’t already in your list.

2. Identify line-of-business application owners

Taking the initial list of applications, identify one individual for each application who qualifies as the application owner. Avoid the trap of assigning an application to a group, as ultimately you will need one accountable person for each application to play the decision maker when it comes to approving transition plans and cutover timing.

Note: The application owner is often the person responsible for investment decisions for the application, including whether to modernize the application or not. This can be the same person who escalates if there are any outages in the application today, but it doesn’t have to be.

At the same time, identify a “Technical Lead.” This is usually someone in IT who has experience with supporting the application, or even deploying it originally. Like the application owner, you’ll want to appoint one lead person here.

3. Aggregate server and database inventory

Pulling all your existing resources together helps to size the migration problem and quantify the opportunities to consolidate resources and improve utilization in the cloud. Similarly, for the servers you do still want to lift-and-shift in a rehost migration, this data can help to right-size VMs in the cloud*.

* In 2020, you are unlikely to rehost the majority of your applications over the more popular replatform and refactor migrations. But if you do, do it right-sized.

To pull together your server inventory, integrate your hypervisors into your database, ensuring that you pull in server hostnames and resource statistics. IPAM tools like LightMesh or BlueCat Networks, and even CMDBs, can also present server inventories that can help identify hostnames within your environment scope.

For bonus points, capture resource allocation, and utilization from the server’s perspective with a daily cron job or Scheduled Task, you’ll be able to measure your resource utilization rates throughout your cloud migration to demonstrate progress. See this open source library for how to quickly pull these machine stats.

For database inventory, you want to layer the instances in your environment on top of the server inventory you have just imported. To do this, use your operational tools to extract and import these catalogs to your inventory. This is an important step to take, as data-gravity in cloud migrations often means that where your data goes the applications will follow.

4. Technology detection

With your application endpoints and server inventory captured, we now need to identify the technology composition of these applications. Use automation tools to analyze your application and database technologies, as spreadsheets and CMDBs are generally out of date here.

Thankfully, we now have agentless discovery tools and techniques for scanning application source code, database configurations and running web applications in minutes. Resist the temptation to do manual analysis, as it’s costly, not scalable and risks confirmation bias when determining migration methodologies: “I found one hardcoded IPs, so they’re probably everywhere.”

Unsurprisingly, automation is key to performing cloud migration assessments across an entire application portfolio.

5. Get the business intent!

You wouldn’t move house without discussing how your family size might change with your spouse, or at least asking them which features of your home they would improve if they could. Right?
So here’s a pro-tip: Don’t migrate to the cloud without first understanding your applications business value, future plans and uncovering any known-issues or user “pet-peeves”.

Create a model of a few data-points that will inform your transition planning and create a questionnaire of around 20 questions to spark a conversation with your application owners.

Spending 15–30 minutes with the business users early-on will pay dividends when you are forming detailed transition plans. Building a dialogue early on in the process also goes a long way to ensuring a smooth cutover and agreeable scheduling to boot! 
Successful cloud migration projects are all about stakeholder alignment, in both timing and IT investment plans.

Migrate with Confidence

With your shiny new application inventory and cloud migration assessments complete, you can now start driving your migration recommendations in a way that both fit your chosen cloud services provider(s) and meet your user community’s requirements.

Remember, in order to reap the benefits of cloud computing, you must migrate your applications with an element of transformation. This replatforming of applications is required to take advantage of the new technologies such as serverless, containers and spot instances that are now available to us all. And while your migration need not be a full-blown application modernization project, it is unlikely to be a lift-and-shift either.

Use the data you have assembled to transform your software enough to achieve a career-making ROI on your migration initiative.

-David Colebatch
Chief Migration Hacker, Tidal

Tidal is a cloud migration platform that gives you application inventory, discovery and assessment all in one place. Delivered as a SaaS platform, you can import your spreadsheets or deploy our tools and get moving today. Results in minutes, not months. Migrate with confidence.

Start a Free Trial today.