Line 214: |
Line 214: |
| | | |
| ==== Determine Rationalization Opportunities ==== | | ==== Determine Rationalization Opportunities ==== |
| + | By the end of this step you will have assessed your portfolio and infrastructure for reationalization and retirment oportunities. |
| + | |
| + | ===== Obsolete Repositories ===== |
| + | There are GC applications – content management systems / web-database systems - that are no longer actively used but maintained because they ''may'' contain information that ''might'' be required in the future e.g. to respond to an ATIP request. |
| + | * Departments should have an active Information Management (IM) function that can verify the actual data retention requirements applicable to a specific application. |
| + | * Departments should recognize the cost of un-necessary data retention and actively dispose of data that has been deemed un-necessary. Un-necessary data is both a cost and a liability. |
| + | |
| + | ===== Obsolete Applications ===== |
| + | Your application portfolio rates the business value of applications. Review low business value applications. Assess whether these applications remain needed: |
| + | * Use access/update logs to identify applications that have received few updates in the past two years. |
| + | * Identify the most recent users and inquire as to the business value of the application. |
| | | |
| ==== Document Migration Strategy and Targets ==== | | ==== Document Migration Strategy and Targets ==== |
Line 220: |
Line 231: |
| 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. | | 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''' | + | ===== '''Choose the Appropriate Migration Strategy''' ===== |
− | | |
| For each application you need to determine you migration strategy (aka the 5Rs). | | For each application you need to determine you migration strategy (aka the 5Rs). |
| {| class="wikitable" | | {| class="wikitable" |
| |- | | |- |
| ! Strategy | | ! Strategy |
− | ! Short Description | + | ! Altnerative Name |
| ! Full Description | | ! Full Description |
| ! Data Centre | | ! Data Centre |
Line 233: |
Line 243: |
| | Retire | | | Retire |
| | Decomission | | | Decomission |
− | | Decomission the application. | + | | Retire, decommission, sunset application. Eliminate it from the portfolio. |
| | | | | |
| | | | | |
Line 239: |
Line 249: |
| | Rehost | | | Rehost |
| | Lift and shift | | | Lift and shift |
− | | ? | + | | Redeploy applications to a different hardware environment and change the application’s infrastructure configuration. Also called Lift-and-shift. Move the solution as is, or with minor changes, to a new hosting environment (small investment of resources). |
| | X | | | X |
| | X | | | X |
Line 245: |
Line 255: |
| | Replatform | | | Replatform |
| | Lift, shift, and tinker | | | Lift, shift, and tinker |
− | | ? | + | | Change OS / Middleware. Requiring some level of application change (medium investment of resources to change). |
| |X* | | |X* |
| | X | | | X |
Line 251: |
Line 261: |
| | Refactor | | | Refactor |
| | Re-architect | | | Re-architect |
− | | ? | + | | Application will be redesigned. Sections of the application will be re-written for improvement/optimization purposes (medium to large investment of resources to change). |
| | | | | |
| | X | | | X |
Line 257: |
Line 267: |
| | Replace | | | Replace |
| | Repurchase | | | Repurchase |
− | | ? | + | | Replace application's functionality by a new solution acquired or developed by department (medium to large investment of resources). The application will be decommissioned once replaced. |
| | | | | |
− | | | + | |X |
| |} | | |} |
| * Address end of life OSes | | * Address end of life OSes |
| | | |
− | '''Rehost (lift and shift)''' | + | ====== '''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. | | 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. | | 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)''' | + | ====== '''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: | | 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: |
| | | |
Line 279: |
Line 287: |
| 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. | | 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)''' | + | ====== '''Refactor (Re-Architect)''' ====== |
− | | |
| Refactoring is the most costly and time consuming of all strategies. This is an opportunity to take full advantage of cloud-native architectures by introducing elastic scaling of resources. | | Refactoring is the most costly and time consuming of all strategies. This is an opportunity to take full advantage of cloud-native architectures by introducing elastic scaling of resources. |
| | | |
Line 289: |
Line 296: |
| Due to the high cost of refactoring, this strategy should be applied to high business value applications. | | Due to the high cost of refactoring, this strategy should be applied to high business value applications. |
| | | |
− | '''Replace (Repurchase)''' | + | ====== '''Replace (Repurchase)''' ====== |
| + | This is an opportunity to determine if Software-as-a-Service solutions for some of the COTS or custom built application you may have running today. Migrating to SaaS is an opportunity to access the latest version of that service and to lower lifecycle management burden. For example, if you operate a legacy email application, you may want to take the opportunity to replace it with Office 365. |
| + | |
| + | ===== '''Choose Your Migration Target''' ===== |
| + | DC or cloud |
| + | |
| + | ===== '''Identify Data Centre''' ===== |
| + | Ensure applications are correctly allocated to its current legacy data centre. The data centre is an essential reporting dimension when TBS tracks your portfolioès progress. |
| | | |
− | This is an opportunity to determine if Software-as-a-Service solutions for some of the COTS or custom built application you may have running today. Migrating to SaaS is an opportunity to access the latest version of that service and to lower lifecycle management burden. For example, if you operate a legacy email application, you may want to take the opportunity to replace it with Office 365.
| + | ===== '''Identify Mission Critical Applications''' ===== |
| + | Ensure mission critical applications are correctly identified. |
| | | |
− | '''Choose Your Migration Target''' | + | ===== '''Identify Operating Systems''' ===== |
| + | Ensure the operating systems for each application are correctly identified. This will be used to ensure all operating systems beyond end-of-life are addressed through a replatform. |
| | | |
− | DC or cloud
| + | ===== '''Generate Portfolio Analysis Dashboard''' ===== |
| + | Request that TBS generate a dashabord of your application portoflio. This will ensure your decisions have been correctly reflected. A sample of the dashabord that is generated is found here: |
| | | |
− | '''Identify Data Centre'''
| + | (insert image here) |
| | | |
− | Ensure applications are correctly allocated to its current legacy data centre
| + | ==== Engage SSC Project Manager and WLM Factory ==== |
| + | It is likely you have already been working with your SSC Project Manager. If not, talk to your Service Delivery Manager. At this point it would be prudent to work with a supplier qualified on the WLM Factory to help with planning and cost estimates. |
| | | |
− | '''Identify Mission Critical Applications'''
| + | ==== Document Project Milestones ==== |
| | | |
− | '''Identify Operating Systems'''
| + | ==== Document Cost Estimates ==== |
| | | |
− | '''Generate Portfolio Analysis Dashboard'''
| + | ==== Gate2: GC EARB Endorsement and MoU to Release Funds ==== |
| + | (insert sample GC EARB deck here) |
| | | |
− | '''Execution'''
| + | (insert sample MoU here) |
| | | |
| + | === '''Execution''' === |
| Content not yet completed | | Content not yet completed |