PLAN: Doing a migration assessment (step 2 of 3)

Migration Assessment | Binary Tree

In this series, we’re sharing tips around how to do a migration assessment. This is the first step of any migration, in which you discover, plan, and evaluate your project. In this post, we cover step 2 of a migration assessment: planning.

The planning step of a migration assessment is where you get into the nitty-gritty of your migration. We often find with our clients that planning a migration can take much longer than the actual migration itself. But it’s time well spent. The more effort you put into planning up front, the more likely you are to deliver a smooth migration that stays on schedule and on budget, without disrupting users.

Prioritize applications

In the discovery phase, you put together a list of applications, plus details about how you use them. Now, you assign each application a priority. This could be a general score that reflects the difficulty of moving the application to the cloud, balanced against the importance of the application to your business.

To help you prioritize applications, look across these criteria:

  • Compliance: Categorization of data, compliance, sovereignty, and security risk requirements
  • UI and architecture: Current complexity of interface, authentication, data structure, latency requirements, coupling, and application life expectancy
  • Operational: Service level agreements, integration, maintenance windows, monitoring, and insight
  • Financial: Operational efficiencies, TCO, return on investment (or similar measurements)
  • Usage: Overall computer load, seasonal fluctuations in usage levels, types of users (casual vs. expert, always online vs. only occasionally), necessary levels of scalability or elasticity
  • Criticality: Business continuity and resiliency requirements, any dependencies that could be affected by a service disruption
  • Tech specs: memory, # of processors, operating system disk space, data disks, network interface cards, IPv6, network load balancing, clustering, OS/DB version, domains supporting, third-party components/software packages

Choose a migration approach

Next up, you need to decide exactly how you’ll move each application to the cloud (if at all). Here are five options for what you can do next, each with their own pros and cons:

  • Retire: For applications that are reaching their end-of-life, this might be a good time to retire entirely.
  • Replace: Many common business workloads (like Exchange and SharePoint) have equivalent cloud offerings.
  • Re-host: This is the lift and shift approach, in which you migrate applications to virtual machines in the cloud. It’s a quick way to migrate applications as is. The downside is that you’re not updating the application to take advantage of cloud features.
  • Refactor/Rebuild: This is where you convert applications to run on a cloud platform. The upside of this approach is that it takes advantage of cloud features like scalability. But it can also take longer and require more technical skills. Many organizations choose to first re-host applications in the cloud, then rebuild them longer term.
  • Retain on-premises: Some applications make more sense to stay onsite. For example, your country’s regulations might require you to keep your data inside your national borders, but there’s no local Azure region yet available in your area.

Plan the process and sequence

After you’ve grouped and prioritized your applications, you should see a logical migration flow start to emerge. Depending on the number and complexity of your applications, your plan might range from a simple schedule to a complex, multi-year strategic migration roadmap, with detailed plans needed for each application.

One way to tackle this is to start with your simpler, non-critical workloads. These are less risky and will probably be quicker to migrate. Quick wins like this can help you build confidence and quickly show a return on investment. It also gives your team a chance to get familiar with how the migration process works, which will help reduce risks for more complex applications later down the road.

Choose a migration product and approach

You have several options for how you can approach the technical side of the migration:

  • Do it yourself using custom scripts and free tools
  • Do it yourself using products from Microsoft or third parties
  • Engage an expert partner to manage the migration for you, usually with their own products, services, and process

Again, this will come down to the complexity of your migration. For migrations of simple applications, the DIY approach might work fine. But when you start getting into more complex migrations of enterprise software used by hundreds or thousands of people, an experienced partner can mean the difference between a migration that stays on track and one that goes sideways.

Clean up issues

In the discovery phase, you might find a few issues with existing applications that could be helpful to address before you move to the cloud. For example, you might need to upgrade a legacy database or operating system to a more modern version. Or you might need to merge on-premises databases before you migrate them. You might even have a chance to merge several related applications into one as you re-design them for the cloud. Now is a great chance to do this type of housekeeping, so make sure to plan for this in your schedule and scope.

Do a proof of concept

Now is also a good time to run a proof of concept or two, which can help you figure out how exactly your applications will work in the cloud. For more complex applications, this can help reduce surprises during the migration. Use a POC to validate things like:

  • How existing application data will be transferred
  • How traffic will be switched to new application endpoints
  • How the migration could affect users
  • The steps you need to take to monitor and verify that the migration has gone well
  • The process for roll-back if the migration doesn’t go as planned
  • The migration platform and process you’ve chosen

Set the schedule

After all the inputs above, you’re ready to put together a detailed schedule. This project often follows typical software development phases:

  • Coding
  • Testing
  • User acceptance
  • Staging
  • Production deployment
  • Data migration
  • Verification
  • Endpoint cut-over
  • Troubleshooting and rollback, as needed

Get started

Ready to start an assessment of your own? We at Binary Tree are standing by. We’re exclusively focused on helping enterprises around the world plan, move, and manage their way to the Microsoft cloud. As part of this, we do assessments that help you get insight into your collaboration environments, including Office 365, Exchange, and Active Directory. To get started, get in touch.


More in the series:


Source: Microsoft. Cloud Migration and Modernization Playbook. 2018.