AWS Migration Readiness Assessment (MRA)

This depends on the specifics of the workloads you’re moving, the type of migration you’re doing, and your preferred timeline, but in general we will optimize to ensure the minimal necessary downtime. Since this is often a concern, this is one of the first items we’ll address when constructing your migration plan and we’ll discuss strategies and mitigations we can employ to minimize the impact on your business.

Lots. Mission has migrated hundreds of customers to AWS, both from all the providers you’ve heard of and many you haven’t. We’ve been certified by AWS for migrations work with the Migrations Competency, and we are recognized by AWS as the #1 Partner at “recognized revenue” in its Migration Acceleration Program—that means getting workloads on to AWS rapidly and exactly as predicted in our migration plans.

• Rehost – Also commonly referred to as “lift-and-shift,” this strategy involves reproducing your current architecture as much as possible. This can be an ideal first phase for some migrations, but is often the least efficient strategy in the long-term.
• Relocate – This strategy is most-common for inter-AWS migrations or replatforming to a cloud version of an application. This often means moving resources between accounts, VPCs, or regions and is common during acquisitions when a new account architecture is necessary.
• Replatform – This strategy takes advantage of AWS-managed services for your workloads, like moving a database to RDS, moving to AWS-specific hardware, like Graviton, or even modernizing OSes and moving to Linux to reduce licensing costs. Replatforming is a great option when you want to preserve a legacy application’s structure while reducing its operational overhead.
• Refactor – Also known as “Re-Architect,” this is about modernizing your applications as you move them to the cloud. Often there can be significant performance and cost wins for re-architecting some or even all of your workloads as part of a migration and engaging with this option is often ideal for cost of ownership.

The truth is, you won’t—not until you’ve accurately assessed your business and cost objectives. Some businesses think they will prefer a simple migration that reproduces their current architecture but discover the inefficiencies aren’t acceptable. That’s why we make assessing your current state and business objectives a part of every engagement—to help you find the combination of optimization, timeline, and cost of ownership that best meets your needs.

This comes down to preparation, planning, and execution. Knowing what you’re attempting to migrate, what critical systems you need to have online, elements of your architecture that depend on a given service’s availability or consistency—all of these elements can create downtime if they’re not appropriately managed. We’ll work with you to identify these critical components of your system and come up with plans to mitigate the effects of a transition and make it as seamless as possible.

The real answer is: it depends on how complex the workload is and the migration strategy. A lift and shift strategy, for example, can be faster than a refactor strategy—but it may also take more tuning and right-sizing to meet your performance and cost objectives. Some migrations take weeks. Some unfold over multiple phases while taking a year or more. But you won’t know the real answer without an accurate assessment of your current environment and objectives for AWS adoption.