Moves without surprises
The costly mistakes in a migration are the silent ones: a name that already existed and was taken over, two things merged that should have stayed apart, a whole account folded into another. TenantShuttle's move plan is built so that none of them can happen without someone saying yes to that one item.
Every name is checked three ways
A move creates names in the destination. Before the plan can be approved, each one is checked against everything it could collide with, using each cloud's own rules for where a name must be unique, its case, its length and the characters it allows.
What the destination holds
The destination is collected read-only, the same way as the source, so every name is compared with what is really there, in the same account, subscription, region or group.
Names unique across every customer
Storage bucket names and service addresses belong to the whole cloud, not one account. On request, TenantShuttle asks the cloud's public endpoint whether each proposed name is free, anonymously, and records the answer.
The plan itself
Two sources that would land on one name, once case and the cloud's own rules are applied, are caught before either is created.
Every clash comes with a way out
For each clash the plan suggests fixes, best first, and the person planning the move picks one. The choice is recorded in the plan with who made it and when.
- Rename by rule, with a suggested name that fits the destination and is checked to be free
- Put it in another account, subscription, group or region
- Use the object that already exists, or leave the item out
- Rename the existing object, only with its owner's permission
No overwrite, no merge, no account folded into another
Any item whose result would overwrite something in the destination, merge into it, or put resources into an account the destination already has is held. Approving the whole plan is not enough: a named person approves that item, after reading its notice.
What exists
The object or account already in the destination, as it was read: its name, where it is and what it holds.
What will change
What the item would do to it, row by row. For a whole AWS account joining another organisation: which policies stop and start applying, who pays, what happens to its tags, shares and integrations.
What cannot be undone
Said plainly, before the approval, with the vendor pages it was checked against. Approvals can be signed, and an approval whose signature does not verify counts for nothing.
Whole accounts are moved, never merged
An AWS account that joins another organisation keeps its identity, its resources and everything inside it. When two accounts clash, the plan flags it and suggests fixes; it never resolves a clash by merging them.
A plan that notices when the world moves on
Choices and approvals lapse
Each choice and approval covers the facts it was made on. When the source or the destination changes, the item is asked again instead of running on stale facts.
Nothing runs unapproved
An item runs only when it is ready or approved. Anything else is skipped and reported, so the default is always to leave things as they are.
Planning changes nothing
Building a plan, choosing fixes and approving items read and write only the plan, which is encrypted like the project.
Where moves stand
Planning is available today: the move plan, its name checks, its fixes and its held items, as a report and as a plan file, from AWS to any of the nine destinations TenantShuttle has paths to.
Carrying out moves is in development, one path at a time, starting with moving a whole AWS account into another organisation. Each path is proven in a lab, end to end, before it is offered to anyone.
Planning a move after a deal?
Tell us what you are moving from and to. TenantShuttle is available on request.