Any company adopting public cloud computing as part of its IT service delivery strategy is faced with the decision of which applications to migrate and how. Some common options we discuss with customers are:
- Move existing applications “as is”
- Build a cloud server from scratch
- Replace with a SaaS application
Each of these approaches has benefits and tradeoffs, and the right decision depends on the company’s business objectives and the application itself.
SaaS applications are dominating new application development these days and for good reason:
there is no infrastructure to buy or maintain, minimal IT maintenance is required, and the low upfront cost and consumptive billing model are all attractive. For a new business looking for applications at a low upfront cost, SaaS applications are a “no brainer.” And for companies looking to offer new applications as part of their IT service offering, SaaS applications have strong appeal.
However, in a scenario where a business wants to migrate an existing on-premises application to a SaaS application, things get more complicated. The considerations include data migration, transition downtime, lost customizations, and return-on-investment for the effort. Depending on the application and scope of the migration, these factors can offset some gains of the SaaS application.
Building from scratch is ideal for customers looking to update an application’s infrastructure/architecture as part of the migration. For example, perhaps the application is based on an older version of the host OS or component application like SQL, but IT has been reluctant to upgrade, preferring the stability of the time-tested version. In this case, a cloud migration may be the best time to do an upgrade since the business will already be factoring in downtime and other impacts.
This manual migration could also allow custom applications to be re-architected for use in the cloud if necessary; very useful if the business intends to migrate an entire complex application to a public cloud. Tradeoffs may include a painful data migration, re-engineering of any customizations, an extended regression testing cycle, or other impacts that could offset the benefits of the upgraded application infrastructure and negatively impact the cost benefits of moving to the cloud.
The third approach is to migrate the application, or application components, “as is” to the cloud provider of choice. In this approach, the entire “stack” (OS, application, and configuration) of a server is captured and migrated to a new cloud server instance. This approach is typically the fastest and most cost effective, as down time and regression testing are minimized since the changes required for the application to function are typically low impact, often only requiring minor configuration changes.
This approach is excellent for simple 1-2 server applications, complex multi-tier applications that are “cloud ready,” and even complex hybrid applications that will maintain application components in the businesses’ private cloud or data center. Of course, any existing application limitations will still apply and some applications may be better candidates for other migration approaches.
Our experience tells us that there is no simple answer to the question of the “best way” to migrate to public clouds. Which of the three approaches will work best depends on your specific circumstances. Don’t be surprised if you actually find that it is beneficial to use one more than approach within your company. For example, maybe one application can be replaced by SaaS, while others can just be hosted in the cloud. Do a comprehensive assessment, remember that not every application makes sense in the cloud, be flexible, and have a safe journey.
Lawrence Guillory is the CEO of Racemi Inc., an Atlanta-based business that builds rapid cloud migration software for enterprises, MSPs, and OEM partners. Racemi’s cloud migration technology provides built-in automatic conversions for any-to-any cloud migrations which allow customers to use their existing server images rather than having to rebuild for the cloud.