Implementing transition strategies

App by app migration

With this strategy, a single application or family of related applications is migrated to a set of workload accounts, which exist in parallel with the existing infrastructure for the application. After the migration is complete, unused infrastructure in the original accounts can be decommissioned.

1. Select a workload for migration and add related resources to a project in preparation for tracking resources during migration.
2. Update the workload as needed to make it configurable and able to run in all locations. These updates might involve code changes to parameterize hostnames, URLs, IP addresses, and ports.
3. Deploy infrastructure as needed in the nonproduction and production workload accounts by deploying architectures from projects that are hosted in the business unit hub account. Ensure that appropriate access, networking, and dependencies are in place as part of the infrastructure setup.
4. Configure delivery pipelines to deploy the application to both the original and new infrastructure such that application deployment is synchronized in both environments.
5. Migrate data by backing up, restoring, and syncing all related data from the original data storage or service. If periodically migrating data, this step might need to be repeated before applications are activated on the new infrastructure.
6. Test the new deployment, update the infrastructure and application, and return to step 2 or 3 as needed.
7. Activate applications on the new infrastructure. For example, update DNS records and load balancer. Consider routing only a percentage of traffic to start if data can be synced live. Ensure that a failback is available in case issues occur.
8. Decommission any unused resources from the original deployment. Use the project configuration from the preparation phase to help locate these resources and complete bulk operations.

This strategy is low risk and gains all of the cost and operation savings that are associated with shared infrastructure and IaC managed workload accounts. Using parallel infrastructure allows for a smooth transition and easy failback should problems occur. However, this approach does temporarily double infrastructure costs and can be slow to run. Also, data sync and infrastructure migration can be difficult. In addition, data services encrypted with BYOK might have extra concerns with migration. For more information about data migration, see relevant capabilities. Despite these drawbacks, this workload migration strategy is likely the best for most organizations.

Piecemeal migration (nonproduction)

With this strategy, nonproduction workloads are moved into separate workload accounts.

Options:

• Use the same process as app by app migration, but migrate only nonproduction workloads. Because nonproduction workloads don't typically have critical data, it might not be necessary to migrate data and even if it is, a period of downtime during the migration can often be much easier to manage.
• Bulk migrate your nonproduction workloads to new infrastructure. This is a similar process to app by app migration, but the infrastructure for a group of nonproduction workloads is deployed and those workloads are switched to deploy to that infrastructure all together. Bulk migration is most appealing if data migration is not required.

Migrating nonproduction workloads into a separate account from production workloads provides an important separation of concerns, making it easier to ensure that users and processes don't accidentally operate against the wrong data or service. Moving only nonproduction workloads eases data migration concerns and further reduces risk as production isn't touched. This strategy works well combined with Transform in place for the production workloads.

Piecemeal migration (networking and shared services)

With this strategy, networking and shared services are set up in a new account and then linked to existing workload accounts, which creates a hybrid architecture. This strategy works well with piecemeal migration of nonproduction and isn't required when using app-by-app migration as a duplicate set of these services can be used instead.

1. Add any existing networking and shared services to appropriate projects in the central administrative account in preparation for tracking resources during the migration.
2. Deploy new networking and shared services in the new network and services hub account according to the enterprise architecture. You must also assign appropriate access.
3. Export transit gateway information and direct link information from any existing deployment of those services.
4. Configure the new transit gateway to use a direct link connection.
5. Configure the direct link, by using knowledge from previous direct link
6. Use exported transit gateway information to connect existing VPCs in the original accounts to the new transit gateways.
7. Setup required keys in HPCS or KeyProtect for any BYOK protected services that you require. If existing BYOK-protected services are being retained, this involves reimporting key material and updating the configuration of those BYOK-protected applications as described here.
8. Optionally, migrate any shared applications following an application migration pattern.
9. Decommission original networking and shared services by using projects to locate redundant resources and support bulk operations.

Existing VPCs might have overlapping addresses that conflict with a flat network design. You must resolve overlapping addresses before implementing the flat network described in the enterprise architecture. This strategy is often best used after separating nonprod from production workloads so that these network changes can be tested with nonproduction workloads. Migrating Key Protect and Hyper Protect Crypto Services to a new account to be used by existing services with KYOK is challenging and might not be possible for all services. Consider leaving existing BYOK protected data services unchanged and using only the new instances of Key Protect/HPCS to protect new data services.

Piecemeal migration (identity and access management)

With this strategy, identity and access management (IAM) is configured in new accounts to support existing user's job functions. This strategy works well with app by app migration.

1. Analyze existing access groups, access policies, and trusted profiles to determine which groups of users are permitted which general access. Use IAM audit reports as needed.

2. Analyze these groups of users to determine their job functions, for example, developer, operations, or finance.

3. Map those job functions into access policies tied to access groups within the enterprise architecture. The enterprise architecture uses an Infrastructure as Code (IaC) approach, so users don't have direct write access to resources. Instead, users have write access to projects, which are used to deploy and update resources.

4. Update deployable architectures so that the correct access groups are provisioned, trusted profiles are created, and so on. This should include all workload accounts and administration accounts to make sure that users have the correct access for their job functions.

Do not migrate existing access directly into the new architecture, as best practices for access needs to be adopted as a part of this transition. Use trusted profiles, access groups, and projects as a means to create and update resources. The results of adoption are better governance, security, and ease in understanding user access.

New applications only

This strategy doesn't attempt to transition existing applications. Rather, it builds out parallel infrastructure for the workload accounts and deploys new applications into that environment. This strategy can be combined with a transform in place, and potentially some piecemeal migration of major common functions like networking and access management.

1. Existing applications remain in place. (option) Consider transform in place for these.
2. Newly developed or newly migrated to cloud applications are deployed to new workload accounts in alignment with the Enterprise Architecture recommendations.

This strategy is safe and easy, but does not attempt to address existing applications and workloads. The Enterprise Architecture benefits will only apply to new applications.

Transform in place

With this strategy, data migrations are avoided and existing accounts and resources are refactored to better align with enterprise architecture recommendations. Certain common operations need to be considered, but the exact refactoring operations depend on your enterprise's starting point, resulting in various substrategies.

Adopt Infrastructure as Code

Move from manual resource management to using infrastructure as code, deployable architectures, projects, and schematics to deploy and update resources.

1. Create deployable architectures to manage your existing resources. Use Terraformer to reverse-engineer existing resource deployments into terraform automation and terraform state. Generated terraform and any previously existing terraform can be used to help create deployable architectures. See relevant capabilities for more information.
2. Create a series of projects in an administrative account that's separate from your workload accounts. These projects are used to maintain the existing infrastructure by using IBM Cloud project governance.
3. Restrict access to existing resources so that changes can be made only by using projects.

This strategy allows existing workloads to continue to run unchanged, but shifts into an Infrastructure as Code mode of operation that is better governed and more repeatable. To reduce risk, new IaC should be used to update nonproduction workloads before production.

Separate production and nonproduction

An alternative to migrating nonproduction to new accounts is to use access groups, resource groups, tags, and naming conventions to separate nonproduction workloads from production workloads.

1. Identify all nonproduction and production resources and apply a "nonproduction" tag and a "production" tag to ensure visibility. Also consider adding a prod or nonprod prefix or suffix to the name of all resources.
2. Apply access tags to nonproduction and production resources or use existing resource groups if they happen to properly separate nonprod and prod. Resource groups can also be renamed with and prefix or suffix to make their role clear.
3. Adjust the access policies so that users have access to nonproduction, but have limited access to production.

This strategy provides some of the benefits of the recommended nonprod prod separation, but is not as safe over the long run that is compared with separated accounts. Consider migrating to nonproduction for increased safety.

Designate shared compute infrastructure

Rather than hosting every application on dedicated compute (and potentially DB) resources, designate selected existing compute infrastructure for shared hosting. Shared infrastructure saves in hosting and operational costs.

1. Designate selected existing compute infrastructure (for example Red Hat OpenShift Clusters) as shared resources
2. Reorganize so that a single team can manages the shared infrastructure.
3. Make any adjustments required to allow the compute infrastructure to be suitable for hosting multiple applications. This might require introducing namespaces in Kubernetes clusters or load balancer pools for VSI clusters.
4. Deploy new workloads onto the existing clusters. (optional) Consider consolidating some existing workloads onto the shared infrastructure.

This strategy provides many of the shared infrastructure benefits, although it may not be quite an elegant and easy to manage as new compute infrastructure designed specifically for shared use.

Separate backup infrastructure

Adjust existing data services and applications to send their backups to a separate account for maximum isolation.

1. Create a separate account to store backups with limited user access.
2. Adjust backup automation to ensure that backups are stored in a separate region and in the backup account, where possible.
3. Decommission older backups after they are no longer required.

Hub and spoke networking

Refactor the networking to align with the hub and spoke network strategy.

1. Designate the account that currently contains the direct link connection as the network hub account.
2. Connect VPCs to the direct link by using transit gateway in the hub account. This might involve removing transit gateways that are located elsewhere.

This strategy provides most of the network simplification benefits that are described in the Enterprise Architecture, although it might not be quite an elegant and easy to manage as when core network services are provisioned in a central account.

Hybrid (database in place)

The hybrid strategy leaves your existing databases and data services in place, while you migrate applications and nondata services into the new architecture:

1. Leave databases and other data services in place, adjusting only access permissions to align with enterprise architecture recommendations.
2. Migrate the applications and nondata services into the enterprise architecture structure by following any of the strategies that are outlined in this white paper. The App by App strategy is recommended.
3. Configure/update any access policies and context-based restrictions necessary to allow your application to reach the data services across accounts.

This strategy avoids potentially risky data migrations while realizing the benefits of Application workload consolidation, but results in a slightly more complex account architecture as data services are not collocated with their applications. As a result extra care must be taken with access policy and context-based restrictions to ensure that only data services can be accessed appropriately.