In the post “The Business Case Justification for PaaS” we looked at the benefits and a business case for PaaS. In this blog we will look at the steps to create a migration strategy to PaaS including re-platforming legacy applications.
Re-platforming applications includes lift-and-shift (containerizing) applications with minor changes, refactoring applications to adhere to twelve factor app guidelines and complete application rewrites to best leverage native cloud and DevOps. Optimizing applications for PaaS often includes changes to improve horizontal scalability, a move from commercial to open-source software, and leveraging application services like database, caching and logging.
Most large companies have built a portfolio of applications over many years that includes custom and commercial-off-the-shelf (COTS) software. It is not possible, or desirable, to migrate the entire portfolio to PaaS. Not all applications will be appropriate for PaaS and the benefits of migrating applications will vary across applications.
Large-scale application migrations require an inventory of applications, a categorization and prioritization of those applications and a prescribed migration plan. Most companies will need formal IT budgets and timelines that may span multiple years.
When looking at the application portfolio holistically, most large companies will find applications that are outdated and have duplicated business capabilities across systems. Many of these applications can be migrated to SaaS, consolidated within packaged applications or deprecated altogether. It is important to reduce the size of the application footprint considered for migration and to determine the level of effort justified to spend on optimizing each application.
From a business perspective, it is best to invest in systems that have the greatest business impact in terms of revenue, cost and customer experience. Application migrations are often tied to a larger business-level, digital-transformation strategy. In the strategic view, a migration road map aligns business goals and the desired customer outcomes with systems plans and activities that provides incremental business value for each application migrated. By starting with high-value applications business value can be delivered early in the migration. This most often translates to migrating customer-facing applications first.
From an IT perspective, it is necessary to analyze and model the as-is state of the application portfolio and categorize systems in terms of complexity, risk, dependencies and business capabilities. In the IT view, application migrations to PaaS may be a part of a larger cloud-first strategy. The business and IT views then must be aligned to create a comprehensive transformation road map. The road map should also address IT capabilities (e.g. DevOps) and platform readiness – people, process and platform. Budgets, timelines and application transition diagrams can be created based on the higher-level road map.
Migration Road map
The first step is to inventory and categorize the candidate applications for migration. During the inventory use a template to capture application details (such as, contacts, business domain, user counts, programming language, etc.). Some applications may be eliminated or postponed from the migration list based on technology fit, lack of use, etc.
The remaining candidate applications should be prioritized based on a set of evaluation criteria such as the following:
Business Metrics
• Business Domain
• Strategic focus / investment themes
• Operational effectiveness
• Revenue generation
• Usage / user count
• Relative User experience
IT Metrics
• Support costs
• Data and integration quality
• Architecture alignment
• Code quality
• Reliability
• Agility
• Security
Next, you can categorize the migration strategy for each application for example as follows:
• Retire
• Migrate to SaaS
• Migrate to PaaS
• Lift-and-shift to IaaS
• Re-architect, refactor / rewrite
• Leave on-premises
Then, applications that have been selected for PaaS migration need to be assessed for an application level migration plan.
At this point automated tools can be used to gather application run-time details, code analysis and supplemented with interviews to collect the following information:
• Application profile – workload characteristics, application architecture
• Non-functional and disaster recovery requirements
• Programming language and framework support
• Application native OS dependencies
• External dependencies and integrations
• Application services requirements – database, logging, session management, etc.
• Build and deploy requirements
• QA lifecycle – test cases, automations, dependencies, etc.
• Level-of-effort estimates and environment sizing
Once you have a solid migration plan here are some tips to get started with your migration:
• Select and adopt the right tools for your environment and culture
• Start with a proof of technology and be prepared to make changes
• Set up the tooling environment, lightweight architecture guidelines and best practices
• Limit the initial scope (start small), measure and gauge effectiveness
• Adjust and incorporate emergent patterns and best practices
Perficient has teams of highly experienced strategists, PaaS developers, DevOps and change management experts should you need any help with your migration. We have invested in training experienced individuals on the latest development approaches including native cloud development, PaaS, DevOps, microservices and re-platforming.
PaaS Service Offerings
Eric, thanks for sharing this post – it’s a great overview of the options available to any firm hoping to make the migration to PaaS the first step in their Digital Transformation.
Although most of the migration work I do these days is focused on eCommerce businesses, even in other sector sI’ve noticed similar patterns and I was hoping you might share in the comments if you have seen similar trends among the successful and unsuccessful migration attempts…
You mention 3 primary strategies for PaaS migration:
1. Lift & Shift (via Containerizing Apps or migrating to the PaaS native virtualization platforms) with only minor changes to the applications being migrated…
2. Reboot of the Application to leverage the best practices of The 12 Factor App
3. Completely re-write the application to leverage the PaaS vendors cloud-native toolset
Most companies I’ve seen adopt the Lift & Shift approach either plan for this as a backup plan if Option 2 or Option 3 run over projected cost or time constraints, though I have seen a few that planned this as their primary strategy. I was wondering if you noticed the following when evaluating project success at the end of the migrations:
1. Lift & Shift is hands-down the fastest migration option with the least overall risk of breaking the project budget or running over the allotted project timetable, especially if you are just migrating from one virtualization platform to another. It gets a little less predictable when you start trying to migrate from VM’s to Containers and orchestration platforms, but of all the three options, this approach requires the least re-learning and re-tooling for DevOps teams and can probably BEST leverage the talents of your existing skillsets across the spectrum of IT Services. Has this been consistent with your own project experiences?
2.Although it easy not to exceed budget or time allocations for the Lift & Shift project work, as soon as the application(s) are at their regular utilization patters on the new platform, actual operational costs are substantially greater than they were when running the VM stack on your own hardware. This is partly due to the fact most internal VM hosting environments are incredibly over-provisioned and the cost structure of traditional IT provides few incentives to optimize these costs compared to a PaaS who has painstakingly optimized their compute platforms and fine-tuned the offerings for very specific workloads. It’s also partly to incentivize customers to build their applications on top of the the PaaS Vendor’s Cloud-Native offerings which are specifically optimized for their own scale & utilization levels.
By “piggy-backing” on their customizations to (for Example) Redis or Memcached (via AWS Elasticache) or NFS (via AWS Elastic File System) you can run AND manage your workloads far more cheaply than if you managed the VM’s yourself. Your teams will have to give up full control of the environments and wind up having to learn a non-trivial amount of new operational techniques as well as the idiosyncrasies of the PaaS vendor’s implementation, but on the flip-side you usually get a much higher level of availability than you could build and manage successfully for the same operational budget as well as auto-scaling at much less complexity than dealing with the challenges of managing VM clusters and native platform support.
I’m curious if your experiences reflect similar trends.
Also, when I’ve seen clients attempt #3 or #2, it’s usually driven by a significant disconnect between their internal assessment of the maturity of their business unit’s DevOps, Agile, and Digital Transformation progress and reality. These businesses correctly identify that option 2 or 3 is probably the best option over the long-term, but underestimate the difficulty of working through the various issues that crop up when trying to manage change across several organizations. Even worse, when these projects DO inevitably go over budget / time, it can substantially weaken the stakeholder support for future migrations, making it even more difficult to generate the internal support needed for a truly successful migration and Digital Transformation Initiative.
I was wondering if you noticed the same or if the projects you worked on followed a different set of trend patterns.