You have classified your data. You know what needs to move onshore, what can stay hybrid and what should stay offshore. Before the migration starts, you need the systems that govern it. This is the migration control plane.
Most teams skip this step. They start moving data and figure out access control, monitoring and deployment pipelines as they go. That works until something goes wrong. Then they are debugging a cross-account permission issue at 11 p.m. while the cut-over clock is running.
Setting up the control plane before anything moves is the difference between a controlled migration and a fire drill. Here is what it includes and how to set it up.
What a migration control plane covers
The control plane is the set of systems that govern how the onshore and offshore environments connect, who can access what, how changes are deployed and how you know the system is healthy. It has four layers.
Identity and access. Who can do what in each environment. What roles exist. How authentication works between environments. What happens when someone leaves the team or changes roles.
Networking and connectivity. How the onshore environment talks to the offshore environment. How traffic is routed. Where the boundaries are and what crosses them.
Deployment and configuration. How changes are rolled out across environments. How configuration is managed. How rollbacks work.
Monitoring and observability. How you know the system is healthy. What metrics matter. Where logs go. Who gets paged.
Each layer needs to be designed before the first workload moves. If you design them during the migration, you make decisions under pressure that you would not make under normal conditions. Some of those decisions become permanent, because nobody goes back to refactor a working setup once the migration is complete.
Identity and access: the foundation
Start with identity. You need to decide how the onshore and offshore environments authenticate to each other. There are three patterns.
Single identity domain. One set of identities works in both environments. If you use AWS IAM for the offshore estate, extend the same IAM structure to the onshore environment. Simple to set up, easy for teams to understand. The risk is that a compromise in one environment becomes a compromise in both.
Separate identity domains with federation. Each environment has its own identity store. Users authenticate to each environment separately. Federation links the two so users do not need separate credentials. More complex to set up, better isolation. The standard choice for production workloads.
Fully isolated identity domains. No cross-environment authentication. Users have completely separate accounts and roles for each environment. Maximum isolation, but the operational overhead is high. Usually overkill unless there are specific regulatory requirements for separation.
For most banks and fintechs, the second pattern (separate domains with federation) is the right call. It gives isolation without making the teams hate you.
Once the identity model is chosen, audit the existing roles and permissions before migrating anything. Every migration project surfaces access-control debt. Find it early.
Look for:
- Orphaned roles (roles that exist but have no principal assuming them)
- Over-permissive cross-account trusts (trusts that allow access from accounts or services that no longer need it)
- Missing service control policies (policies that should restrict which regions or services an account can reach but have not been applied)
Fix these before the migration starts. Every one of them will cause a problem during cut-over if you do not.
Networking and connectivity: where the boundary lives
The onshore and offshore environments need to talk to each other. The question is how.
The simplest approach is a VPN or direct connection between the onshore colocation and the offshore cloud environment. Traffic between the two goes through an encrypted tunnel. This works for most workloads.
The more scalable approach is a cloud router or transit gateway that connects all environments. Traffic routing is managed centrally. Adding a new environment (a second colocation, a new cloud region) becomes a configuration change, not a network redesign.
Whichever approach you choose, document the traffic flows. Every connection between onshore and offshore should have a reason and an owner. If a connection exists and nobody knows why, it is a security risk.
Also document what does not cross the boundary. The circular says payment transaction data stays onshore. Your network design should enforce that. If the network allows transaction data to leave the onshore environment, the compliance question comes back regardless of what the policy says.
Deployment and configuration: how things move
Your deployment pipeline needs to work in both environments. If you deploy to offshore with a CI/CD pipeline and deploy to onshore by SSHing into a server, you have a problem.
Start by making sure your deployment tooling works in both environments. The pipeline should build once and deploy to either environment based on configuration. The artifact that runs offshore should be the same artifact that runs onshore. Different configurations, same code.
Configuration management is the harder problem. Each environment has different endpoints, different credentials, different network addresses. You need a mechanism to inject environment-specific configuration without hardcoding it into the application.
Environment variables are the simplest approach. A parameter store or secrets manager is better for production. The important thing is that the application does not know which environment it runs in. It reads its configuration at startup and behaves accordingly. This makes testing easier and reduces the risk of environment-specific bugs during cut-over.
Monitoring and observability: how you know it is working
Once data starts moving, you need to know it is still working. Not that it was working when someone checked an hour ago. Working right now.
You need metrics from both environments in the same dashboard. If offshore metrics go to one tool and onshore metrics go to another, you will miss problems that span environments.
Set up:
- Latency metrics for every cross-environment data path. Latency changes are the first sign of a problem.
- Error rate metrics for every service that touches payment transaction data. A spike in errors on the onshore side means the migration is causing a regression.
- A health check that confirms the onshore environment can serve traffic independently. This is the most important test. If the offshore environment goes down and the onshore environment cannot handle the load, the migration is not complete.
- Log aggregation across both environments. When something breaks, you need to trace the request from end to end regardless of which environment handled it.
The order of operations
The sequence that works:
- Set up identity and access (separate domains with federation)
- Audit and fix existing access-control debt
- Set up networking connectivity between environments
- Set up deployment pipelines for both environments
- Set up configuration management
- Set up monitoring and observability across both environments
- Test the control plane by deploying a non-production workload end to end
- Migrate the first production workload
Steps 1 through 6 are the control plane setup. Steps 7 and 8 are the migration. Do not start step 8 until steps 1 through 6 are complete and tested.
A bank or fintech running 30 to 50 services can set this up in three to four weeks with two engineers. The time is not in the tools. The tools are standard (Terraform for infrastructure, GitHub Actions or GitLab CI for pipelines, Datadog or Grafana for monitoring). The time is in the decisions: which identity model, which network topology, how to handle secrets, how to handle rollbacks.
Make those decisions before you start moving data. The migration itself will go faster, and the team will sleep better during cut-over.
The position of this Journal
The control plane is the part of a migration that never shows up in the project plan, and it is the part that decides whether cut-over is controlled or chaotic. Kaliabe designs and operates this control plane for institutions moving to sovereign infrastructure: identity, connectivity, deployment and monitoring, specified and tested before the first workload moves. The migration is the visible work. The control plane is the work that makes it safe.
FIG. J4 — MIGRATION CONTROL PLANE · IDENTITY · NETWORK · DEPLOY · MONITOR · SET UP BEFORE THE FIRST WORKLOAD MOVES