Migrating a web-based application from its in-house computing environment to a vendor-managed, cloud-hosted computing environment should be easy. While a migration is not a high-risk, stress-inducing project, there is a significant list of requirements that you should consider in your migration project plan. Addressing these requirements will ensure you achieve a smooth migration to the cloud.
Will the in-house application run in the cloud environment?
Most in-house applications rely on more pieces of infrastructure and more software components than is immediately evident. Here are the major components:
For the computing infrastructure layer, the cloud environment will require a compatible database management system, equivalent middleware, application development tools and operating system versions.
For transaction operation, the cloud environment will require compatible database servers, application servers and web servers.
For business intelligence operation, the cloud environment will require a compatible data warehouse and analytics software with a development capability.
More and more applications also make use of email and document management that the cloud environment will have to offer.
Will the cloud environment satisfy non-functional requirements?
End-users have expectations for online response time, batch performance elapsed time, availability, remote accessibility, failover, backup & recovery and disaster recovery.
While your in-house application may or may not meet various expectations today, it’s highly likely that end-user expectations of the cloud environment will increase once the plan for the migration to the cloud is announced.
These heightened expectations often trigger:
- A wide area network upgrade between end-user premises and the cloud environment.
- An increase in the base capacity of the cloud environment that is being acquired.
- A need to test application performance, failover and backup & recovery.
Naturally, you will want to include these non-trivial items in the migration project cost estimate.
Can the cloud environment comply with applicable requirements?
Every organization is expected to comply with various security, privacy and regulatory requirements that are defined by contracts, governments and regulators.
These requirements are an inescapable part of the scope of the migration project to the cloud. Examples include PCI, the Privacy Act, Personal Information Protection and Electronic Documents Act (PIPEDA), USA Patriot Act, European Union (EU) Data Protection and the EU ePrivacy directive.
Testing to ensure a reasonable level of compliance will consume significant resources and elapsed time.
How will the cutover to the cloud environment occur?
Once you are satisfied that the application is running well in the cloud environment, the moment to migrate your end-users to the cloud is usually at hand.
If your number of end-users is modest and the need for moment-to-moment application availability is not high, the Saturday night cutover is typically preferred because it’s fast, cheap and low risk.
However, if your number of end-users is significant, external organizations access the application and the need for moment-to-moment application availability is high, your cutover becomes a more expensive multi-stage process. Now end-users will migrate in carefully-scheduled groups and the in-house database must be well synchronized with the cloud database during the migration period.
Is it really a migration or an application upgrade?
Sometimes the migration project to the cloud isn’t really a simple migration but a much more ambitious effort to add various improvements under the guise of a supposed migration project. This misleading situation is fraught with risk and future disappointment. For example, your migration project to the cloud may also be expected to deliver functionality enhancements such as notifications or a migration from the current Windows operating system to Linux.
In this situation, consider that there are at least five ways to migrate applications to the cloud that go beyond the simple migration I’m describing here. The added scope of these alternatives dramatically adds cost and risk to your migration to the cloud.
Can you share any experiences gathered from projects that migrated your applications to the cloud?
