Of the seven Rs, replatforming tends to be the answer when organisations are looking to achieve tangible benefits without adding major new functionality or changing the core architecture of an application or service.
These benefits typically come from updating or optimising to take advantage of the strengths of the cloud. There are ways to achieve this through replatforming with minimal code changes. Beyond this, replatforming projects are in danger of blowing out into unintended refactoring efforts that embark on major changes.
What are the benefits of replatforming?
From a technology perspective, replatforming offers applications access to cloud-native functionality such as auto-scaling, managed storage and managed data processing.
One driver behind replatforming can be automating certain tasks that are essential to operations, but not necessarily business priorities. This may involve moving databases to a database-as-a-service (DaaS) platform, in order to take advantage of automation and an elastic database infrastructure. Alternatively, replatforming may involve migrating an application to a fully-managed platform.
From a business perspective, replatforming tends to be more cost-effective than refactoring as it does not require a major development project. Rather than take the plunge and commit to a large all-in migration effort, replatforming allows organisations to start small.
Business outcomes driving replatforming can include reducing operational cost and effort, improving customer experience through enhanced performance and reliability, and accelerating time-to-market for new features.
What are the risks of replatforming?
One of the key benefits of replatforming is taking advantage of automation. As such, there is a risk that the benefits will be very limited if the application will still require a high level of manual management.
There are also risks if organisations fail to fully appreciate application dependencies and potential incompatibilities with the new platform, leading to unexpected difficulties during the project that perhaps mean that replatforming was not the best choice.
One of the biggest risks when replatforming is inadvertently crossing the line into refactoring due to scope creep, as organisations succumb to the temptation to incorporate more and more changes. Successful replatforming tends to stick with common, well-known cloud components and stay away from dramatic changes unless they are unavoidable and/or represent high business value.
The simple fact of being in the cloud now gives users the opportunity and flexibility to strategise to refactor or even rebuild quickly post migration.
When is replatforming the right choice?
If you are looking to leverage the benefits of the cloud but aren’t prepared to make major changes to your application, then replatforming can be the way forward. For example, if the limitations of on-prem infrastructure begin to hamper performance and scalability, then replatforming to take advantage of the cloud is often the right choice.
Making this decision requires careful evaluation of the existing application and intended platform, including its architecture and compatibilities. Business requirements must also be considered.
It is not the right choice if, due to the nature of the application or platform, replatforming will not solve issues or unlock benefits through minimal changes. In this situation, rehosting, repurchasing, refactoring or retiring may be the better course of action. If an application is a better candidate for refactoring as opposed to replatforming, it is crucial to identify this upfront rather than midway through a replatforming project that is going off the rails.