Services, techniques and use-cases for adopting cloud services and transforming information technology services.
The second in a series of posts for 2020 where the junkshon team will provide insights as to how to migrate services to the cloud. The team has performed many migrations, data centre transformation and applications modernisation and deployment programmes for customers globally.
The topics will range from:
how to perform an efficient discovery
building your landing zone to meet your workload requirements
using the latest cloud services to accelerate your transformation
setting up your delivery teams for success selecting the best migration options managing a programme efficiently and at the lowest possible price point and risk level using technology to help manage the migration/modernisation programme
developing your new operating model
And lots more.
In our second issue, we are looking at the migration treatment Re-purchase, one of the 6Rs of application migration.
The industry definitions for each of the 6Rs are described below.
Rehost. Redeploy an application component to another physical, virtual or cloud infrastructure without recompiling, altering the application code, or modifying features and functions.
Replatform. Migrate an application component to a new runtime platform. Make minimal changes to code to adapt to the new platform, but don’t change the code structure or the features and functions it provides.
Refactor. Restructure and optimize existing code without changing its external behaviour to remove technical debt and to improve the component’s features and structure.
Rearchitect. Materially alter the application code so you can shift it to a new application architecture and fully exploit new and better capabilities of the application platform.
Rebuild. Rebuild or rewrite the application component from scratch while preserving its scope and specifications.
Replace/RePurchase. Eliminate the former application component altogether and replace it, taking new requirements and needs into account.
The Re-purchase treatment is the adoption of a commercially available business application package or service to meet a business need.
At junkshon, we see it in two forms.
SaaS – move to Software as a Service (SaaS) e.g. Salesforce for CRM, Workday for HR, Google for email, etc.
COTS – Commercial Off The Shelf (COTS) – move to a commercially available third-party software product to be hosted in the cloud.
The best candidates for re-purchasing are:
Applications where there is no business advantage in developing and maintaining a bespoke application.
Existing on-premise legacy COTS applications.
Selecting the appropriate SaaS or COTS product to meet your business needs is an extension of your current process for selecting COTS applications with further refinements to your requirements to address SaaS or COTS cloud hosting and operation.
The primary benefits of the re-purchasing for the cloud are;
The rapid adoption of mature business functionality
Adoption of “as a Service” – utility consumption-based model for business functionality
Re-direct resources to areas that deliver competitive advantage
Adoption of a Re-purchasing treatment for your enterprise is the result of an application portfolio assessment that identifies a set of applications where buying SaaS or COTS represents the best value to the business. Often enterprises will have a policy of “Buy before Build” where it relates to business processes and their associated application functionality that does not deliver competitive advantage. This frequently applies to back-office activities such as HR, ERP, travel management, expense management, service management, email, etc.
Some of the key change considerations for re-purchasing are;
Selection process – leverage previous experience of the product selection process and supplement that with new requirements for SaaS, cloud hosting and operation, consumption-based billing, etc. For example, selecting from AWS Marketplace for COTS on AWS solution.
Configuration, customization and data migration. Use best practice for COTS adoption in terms of maximizing the use of standard configuration options and avoid customer-specific customization that prevents product upgrades. Carefully manage any data migration from current applications to the new SaaS/COTS on a cloud solution.
Application integration – new cloud-native capabilities for integrating cloud-hosted applications with SaaS. Re-use of standard APIs for SaaS and COTS.
Other non-technical considerations include:
Cloud capabilities of the COTS vendor. Provision of standard automation templates for deploying COTS package to your cloud platform landing zone. Vendor supported SaaS or managed service cloud delivery models.
Operating Model. Shared responsibility model between you and SaaS/COTS vendor for change management, event management, incident management. Integration in terms of DevOps model, CI/CD pipelines for COTS product upgrades, etc. (See junkshon whitepaper on COTS and DevOps for a more detailed discussion)
Financial models to handle the utility-based consumption model. Pay as you go rather than fixed, long-term contractual commitments.
How can junkshon help?
We can provide rapid estate analysis and advisory and build your mass migration strategy and plan. We understand in detail what it takes to migrate workloads to the public cloud or between data centres.
Check out our strategy package: