Customers are working on a roadmap to do a technology refresh of their current application landscape and/or they are introducing new application. What should remain on-premises? Customers are struggling with questions like: should I use the public cloud? Could I replace some on-premises applications with Software-as-a-Services applications on a pay-as-you-go model? Is it possible to have different strategies for different applications? How does this fit in my roadmap to modernize our current datacenter infrastructure? The model described in this blog could be helpful to answer those questions.
In this model you could start with different (migration) strategies. But, be aware of your overall vision and migration strategy. Before it is possible to introduce cloud services like Azure or Office 365 – in a full public of hybrid scenario – there should be a tenant that is available to use for your enterprise. There should also be a design for connectivity (bandwidth, latency, etc.), security, high availability, etc.
In most cases there are a lot of applications that are hosted in the current environment that could be ‘removed’ from the infrastructure. Those applications are not used anymore and already replaced with other applications. Eliminate those environments. From a technical point of view, this is the easiest step in the migration process. This migration step could be applicable for circa 30% of all applications in the current environment. Retire applications is one method to remove those applications from an ICT landscape, but sometimes it is also an option to do a resize. Check the current load, the number of users, the hardware that is used, etc. and map those information to modern hardware specifications.
Default applications could be replaced from on-premises solutions with Software-as-a-Services solutions. So, replace those applications with purchased SaaS solutions and migration the data to the cloud. Some examples:
| Migration method | Cloud model type | Description | Main activity |
| Rehost | On IaaS | Redeploying to an IaaS environment and changing the application’s configuration to work in a new virtual hardware environment. | Lift & shift |
| Refactor | Using PaaS | Redeploying to PaaS, thereby making use of familiar languages and frameworks while at the same time taking advantage of the cloud characteristics running on top of the provider’s infrastructure. | Lift & Reshape |
| Revice | For IaaS or PaaS | Modifying an existing codebase to meet cloud adoption or legacy modernization goals. Then rehosting or refactoring it to the cloud. | Replace, drop & shop |
| Rebuild | On PaaS | Discarding existing code and rearchitecting the application for a new software framework. Alternatively known as rearchitecting. | Rewriting / decoupling applications |
| Replace | With SaaS | Discarding an existing application and using a proprietary pay-as-you-go SaaS solution instead. | Purchase |
| From | To |
| Office servers | Office 365 |
| Portals and SPS | SharePoint Online |
| Any relationship mgmt | CRM Online |
| Active source control | VSTS |
| Data warehouses | ADL + PowerBI |
| Industry standard verticals | Best 3rd party SaaS |
This replace scenario could be applicable for circa 15% of all applications in the current environment.
The next migration method is to revice, rebuild and/or refactor applications. This is where Azure becomes the public cloud platform. Some functionality could be expose in existing SaaS/PaaS solutions. It is also possible to convert an application with Azure PaaS solutions. The last option is to use virtual machines in Azure as a IaaS service.
The last migration method is to rehost servers from on-premises to Azure. This is a lift-and-shift scenario. Some examples:
| First to move | Next to move |
| Basic web apps | High I/O OLTP |
| Advanced portals | Regulatory and high business impact |
| Any new solutions | |
| Any re-architected solutions |
This rehost, revise, rebuild and refactor scenario could te applicable for circa 50% of all applications in the current environment.
So, what should be remain on-premises? This is about 5% of the environment. Systems that could stay on-premises are: HVA systems, PKI systems and legacy source control.
