Cloud migration shouldn’t be an “all or nothing” proposition or a ‘one migration approach suits all’ application. By spending some time up front to analyse your application portfolio, you can reduce your risk while delivering quick wins to your business – demonstrating value early in your programme.
Some approaches to explore each application
A. “Lift and Shift” approach
This is typically the quickest and easiest approach to migration. It involves re-hosting your application onto cloud-based IaaS (“Infrastructure as a Service”) with minimal changes.
The migration team is required to identify changes to your network, the application configuration and any data integration used by the application. Public IaaS vendors, such as Amazon Web Services and Azure, come with several tools that can automate parts of the migration – reducing time, cost and risk.
There are a few trade-offs to this approach. You may miss out on the benefits of application elasticity and scalability found within IaaS, and you would need to put management practices in place to avoid cloud bill-shock.
Re-hosting is particularly effective as an initial step in a larger cloud migration strategy, realising benefits early and allowing your team to become familiar with cloud operations. We have seen organisations realise cost savings of as much as 30% in some cases.
B. Re-platform the application
Like the previous approach, the application is re-hosted on an IaaS vendor. However, your team would have to make a few architectural changes to the application hosting to utilise some of the key benefits of cloud computing around scalability, redundancy and disaster recovery.
These changes are low risk, allowing you to achieve additional tangible benefits in a timely manner without distracting your development team to make core architecture changes to the application. Developers can continue to utilise existing tools and approaches, minimising changes to their work environments.
Commercial applications could have been evolved by the software vendor. You might find that the vendor is now providing the same or similar function scope as a service, typically known as SaaS (“Software as a Service”).
Unfortunately, you may need to re-purchase their software in this model. Once the procurement cycle is complete, the actual migration is usually focused on data and re-building integrations with the rest of your application portfolio.
This approach can have a few disadvantages around changes to the vendor’s functionality – leading to business change impact, interoperability issues with the rest of your portfolio, and vendor lock-in.
D. Re-architect your application
This approach is based on re-architecting your application to utilise PaaS (“Platform as a Service”), usually leveraging off features and functions supplied by the PaaS vendor.
Typically, you would adopt this approach when the application lacks the ability to adapt to business needs, such as missing features/functions, not meeting scale and performance requirements, or if the application is too slow and cumbersome to change. To align with the changed business environment, the application’s existing architecture would need to be rebuilt to leverage off new software development paradigms such as microservices, APIs and cloud computing.
Despite this approach most likely leading to the longest delivery times, the business agility and benefits can quickly outweigh the negatives. There are additional benefits to be realised by your technical team around moving from a legacy development approach and tooling to utilising leading developer’s tools available on PaaS vendors – such as application templates, pre-built components and data models that can be quickly customised to meet your business requirements.
The primary trade-off of this approach is that your business is highly dependent on the PaaS provider. Any issues that arise around the vendor’s policy, pricing or business operations can affect you. We are seeing a growing trend with our clients adopting container-based solutions, allowing you to migrate application workloads between different PaaS vendors.
E. Consolidate or Retire
Most application portfolios have grown large. Typically several applications have been built or procured over time to fill capability gaps within your business operating model. Over time, vendor software has also been enhanced by the vendors to encompass more functionality.
A key activity in your early discovery phases needs to be the assessment of the functionality of each application and its level of use within the organisation. We typically find that 10% of deployed applications are used by fewer than 5 people. Applications with low usage or overlapping functionality should be assessed to determine if changes to business processes could be used to consolidate or retire the application.
This consolidation reduces portfolio complexity and frees up resources to focus on more business-critical activities. Consolidation not only realises cost savings around migration but also the costs of maintaining these applications, as well as minimising security risks around obsolesce.
Keep in mind when developing your migration strategy that when transitioning to the cloud, you do not need to adopt an “all or nothing” approach. A hybrid cloud strategy can provide the best of both worlds, leaving some applications running in your data centres while migrating others to private or public cloud services. Contact us today for a no-obligation consultation to find out what we can do for your business.