Application Modernization
Departmental Journey
Prioritization
 Assess Legacy Data Centres
|
 Recommend Priority Data Centre Closures
|
 Gate 1: GC EARB Endorsement of DC Closures
|
 Notify Impacted Departments
|
 MoU for funds to support departmental discovery
|
Discovery
|
Application Portfolio Analysis
|
 Engage SSC PM and WLM Factory suppliers
|
 Document Project Milestones
|
 Document Cost Estimates
|
 TBS Oversight Team review of costs, plan, and portfolio analysis
|
Gate 2: GC EARB Endorsement. MoU to Release Execution Funds
|
Execution
 Staff project team
|
 Configure Cloud Platform
(e.g. Landing Zone) |
 Launch Security Assessment & Authorization process
|
 Develop test plans
|
 Execute migrations, security assessments, & testing
|
 Report status to TBS Oversight Team
|
Decommission legacy data centre
|
Discovery
Application Porfolio Analysis
Determine Modernization Vision for the Organization
By the end of this step, you should have discussed with leadership how far you want to take your modernization journey. This will be the vision for your organization. Those who will be performing the subsequent portfolio analysis steps should understand that vision.
This is an opportunity to determine the direction for the organization; is it to largely sustain current operations and culture, or does the organization desire to modernize and be more transformative. Perhaps your organization has already begun a modernization journey. In today's IT environment cloud technologies combined with DevOps methods are having a large impact on how IT is delivered. Amongst the goals of these technologies and methods is to decrease lead time and time to market; in summary
- deliver IT faster
- Increase reliability
- Increase security
- Increase quality
This guide does not instruct an organization how to undertake its modernization journey, but instead meant to be a catalyst for establishing the vision. These changes can be wide sweeping impacting roles, responsibilities, and culture. They are not undertaken in a year, but instead must be seen as a journey of maturity and continuous improvement.
While some organizations have started this journey years ago and are ready to go "all in" on cloud and the workforce are DevOps practitioners, others have not begun the journey.
For those who have not yet begun a modernization journey the choice may be take this opportunity to start that journey. For others, they may decide to simply sustain operations as-is.
cloud maturity map will be inserted here
A simple visual for plotting you cloud adoption maturity can be found here. Most organizations start small with a few low risk applications. A team of willing and keen developers from within your existing workforce would lead an imitative to migrate those low risk workloads to the cloud. From these experiences they would use their learnings to train others to do the same. As the number of workloads grow, the need for more sophisticated methods such as automation and DevOps will need to be applied. This will facilitate scaling without impacting agility. Existing governance and roles will also need to evolve. An organization should review the [insert roles and reap document here] to ensure your organization is ready to undertake the required roles to support cloud services.
A simple scorecard has been devised to assess low risk workloads for cloud migration. This scorecard is meant to provide you a short list from which to further decide where to start. Any application can be migrated to the cloud with enough time and effort. The scorecard is meant to identify low risk and low effort migrations.
For organizations that desire to forego modernization opportunities, the decision to rehost the entire application portfolio to a new data centre provides that opportunity.
Determine Rationalization Opportunities
Document Migration Strategy and Targets
By the end of this step you will have analyzed your portfolio of applications, updated key data in APM, chose the migrations strategy for each application ( one of the 5 Rs ), and the target for each application ( cloud or EDC ).
During the Determine Modernization Vision for the Organization step you would have determine how far your organization wants to take its modernization journey. Part of that step was the Cloud Fit Scorecard. You should have already narrowed the target options for each application.
Choose the Appropriate Migration Strategy
For each application you need to determine you migration strategy (aka the 5Rs).
| Strategy | Short Description | Full Description | Data Centre | Cloud |
|---|---|---|---|---|
| Retire | Decomission | Decomission the application. | ||
| Rehost | Lift and shift | ? | X | X |
| Replatform | Lift, shift, and tinker | ? | X* | X |
| Refactor | Re-architect | ? | X | |
| Replace | Repurchase | ? |
- Address end of life OSes
Rehost (lift and shift)
With a rehost migration strategy, the application undergoes no changes and is migrated as-is to a new data centre or cloud. This is the simplest and least effort migration strategy.
For workloads migrating to cloud, it is strongly advised that, at the very least, the resources (network, compute, storage) be optimized and reduced to the smallest size possible. Additionally using reserved instances for production workloads and turning off unused servers during off-hours will help ensure a lower monthly bill from your cloud provider.
Replatform (lift, shift, and tinker)
With a replatform strategy, the application undergoes minor changes as it is migrated to a new data centre or cloud. Replatforming strategies may include, but as not limited to:
Addressing end of life (EOL) software such as those deprecated by IT Policy Implementation Notice ITPINs
Move to Platform-as-a-Service (PaaS). For commoditized services such as databases, web servers, file servers, container orchestration, moving to a PaaS allows for a serverless architecture. A serverless architecture negates the need to manage and patch operating systems, middleware and manage server instances. This also reduces an organization's IT LifeCycle Management burden. Users sometimes worry that using PaaS will cause vendor lock-in. By using PaaS that have alternatives elsewhere in the market will avoid lock-in. Being able to extract your business data and business rules from a PaaS is key to avoiding lock-in. Most cloud providers offer database, web server, and file server platforms. While migrating from one to another may not be completely painless, migration tools and APIs exist to allow for this possibility.
Containers is an increasingly populate method to deploy applications. If your application is stateless, moving it to a container will not only help portability, but also help with your organization's adoption of DevOps practices.
Refactor (Re-Architect)
With a refactoring Make elastic.
Function as a service.
Add DR
Replace
SaaS
Choose Your Migration Target
DC or cloud
Identify Data Centre
Ensure applications are correctly allocated to its current legacy data centre
Identify Mission Critical Applications
Identify Operating Systems
Generate Portfolio Analysis Dashboard