A multi-country education non-profit asked us to move its data portal off a third-party provider's AWS account and onto infrastructure it controlled. The portal had 2,500+ users in more than 10 countries, and it was in the middle of a programme cycle. "Take it down for a weekend" was not an option.
The brief said migration. We ended up recommending something else, and the reason is the most useful lesson I took from the engagement: do read-only discovery before you choose the migration strategy, not after.
Step 1: read-only discovery
Before proposing anything, we got read-only access to the live account and mapped what was actually running:
- compute, databases and storage, and how they were wired together;
- IAM: who and what had access, and how;
- networking and DNS: where traffic entered and who controlled the records;
- backups, monitoring and alerting: what existed, and what we would lose if we moved things.
Read-only matters. Nobody can accidentally break production while you are still learning how it works, and the provider is far more comfortable granting it.
Step 2: the finding that changed the plan
The obvious plan was a classic lift-and-shift. Stand up a new account, replicate the databases, copy the storage, rebuild the services, then cut DNS over during a maintenance window.
Discovery showed that DNS control sat inside the source account itself. That changed everything. A data migration now meant:
- a cutover window that every user would feel;
- recreating every component, and its configuration drift, in a new account, with regression risk at each step;
- coordinating a DNS change with the very provider we were moving away from.
We had another option. AWS lets you move an account from one organization to another, so the account itself, with everything already running in it, could change hands. Nothing moves and nothing gets rebuilt. What changes is who owns and controls it.
Step 3: weighing the trade-off
| Data migration | Account ownership transfer | |
|---|---|---|
| Downtime | Cutover window | None |
| Regression risk | Every rebuilt component | Minimal (nothing rebuilt) |
| Clean greenfield setup | Yes | No: you inherit the existing setup |
| Effort | High | Low to medium |
The cost of the transfer is real: you inherit whatever is already in the account, good and bad. We judged that a fair trade, because the inherited problems could be fixed after the client owned the account, on the client's own schedule, without any user-facing risk.
Step 4: plan it like a migration anyway
Choosing the low-risk path did not mean skipping the paperwork. We still wrote:
- An architecture baseline: what exists today, documented, so the client knows what it is taking ownership of.
- A migration strategy: why the transfer beat the alternatives, in plain language for non-technical stakeholders.
- A week-by-week runbook, with an hour-by-hour plan for transfer day: who does what, in what order, with checkpoints.
- A risk register: each risk, its likelihood and impact, the mitigation, and an owner.
- A provider handover questionnaire: everything the outgoing provider knew that was not written down.
- A target-account specification: how billing, IAM and access should look once the client owned it.
Step 5: sort security findings into "fix now" and "fix after"
Discovery always turns things up. We found security exposures that needed attention. Fixing all of them in the middle of an ownership change would have stacked risk on risk, so we sorted them:
- fix now: anything dangerous enough that it could not wait for the transfer;
- fix after: everything else, scheduled once the client was in control.
Because the client's users were in several countries, we also flagged the data-residency side, including the Kenyan and Nigerian data-protection laws.
The result
The transfer completed with zero downtime. Users noticed nothing, no data moved, and the client ended up with full control of billing, IAM and DNS. The remediation work then went ahead on a calm schedule.
Takeaways
- Discovery picks the strategy. We only found the right plan because we looked before committing.
- Ask "what if nothing has to move?" Moving ownership is often cheaper and safer than moving data.
- Low risk still needs a runbook. The documents are what make a calm transfer day possible.
- Split remediation by urgency so you don't add security work to a risky change.
I'm Trevor Ogina, a senior backend and cloud engineer in Nairobi. I lead teams building Go and Spring Boot platforms on Azure, AWS and GCP. You can find me on GitHub and LinkedIn.
