A refactor migration is the most transformational transition type for our custom applications.
The selection of this transition type is driven by a strong near-term business need to add features, scale, or performance that would otherwise be difficult to achieve in the application’s existing environment.
This pattern tends to involve the largest upfront investment, and is generally reserved for applications that (a) are a core-competency for the organization (b) no suitable SaaS solution exists and (c) offer the greatest business value, either through savings or other agility metrics.
Small modifications to our application to allow it to be deployed to cloud-native services via pipelines. This transition type generally allows us to take advantage of the most compelling cloud computing tenets (elasticity, security, cost-efficiency), with the least amount of effort.
Specifically, here we will attempt to replatform our databases from proprietary engines such as Oracle, to cloud-provider services which remove the operational burdens and are generally priced on a consumption basis. Additionally, we will attempt to replatform our application code to one or more cloud-native services, such as serverless functions and queuing systems, as well as containers.
Sometimes this involves moving to a new product to replace an existing commercial off-the-shelf (COTS) or custom application, but most commonly this transition type is applied to COTS applications that now have SaaS offerings from the vendor. We choose this transition type whenever possible, as it almost always offers the simplest path to doing less “IT” while still retaining the service.
The canonical example here is MS Exchange -> Office 365, removing the operational burden of email infrastructure while arguably providing more than the legacy on-premise solution. Other relevant examples include moving CRM solutions to Microsoft Dynamics or Salesforce.com, and an HR system to Workday.
A rehost transition type is generally employed as a last resort when a compelling event like a datacenter closure, hardware lease, or supportability period end is driving the migration.
The reason the rehost is often a last resort, is that support for applications in a replatform scenario has increased greatly in the last 2 years, leaving little reason to attempt this no-value transition.
Having said that, should rehost be employed, it can be automated with data replication and/or disaster recovery tools.
When we select retain as our transition type, we are doing so because an application is becoming end of life during our migration project at which point it will be retired or “die on the vine”.
Alternatively, this application may be deemed as out of scope, to be revisited for migration later in a subsequent project.