Six stages. The order is the product.
Select a stage to see what the console does and what it hands you. DRAG TO SCROLL →
STAGE 06 — EXCEPTION REPORT
Everything that cannot be migrated, named at discovery time with the reason. This branch leaves the line at stage one — which is what makes it commercially useful rather than a post-mortem.
WHAT IT HANDS YOU
- ›Resource, class, reason, disposition
- ›Scope boundary for the SOW
- ›Priced manual work package
- ›Presales artifact for the proposal
HOW IT ACTUALLY BEHAVES
Discover, plan, adapt, move — then redo only what broke.
A migration plan written before discovery is a guess. Migration Factory writes the plan from the inventory it found, adjusts the destination to what the customer actually needs, and treats a failed resource as a named row to re-attempt — not a reason to run the wave again.
Discover the estate as it is
Not as the CMDB describes it. Every resource, its configuration and the dependencies between them, captured from the source accounts themselves.
INVENTORY + DEPENDENCY MAP
Plan waves from real dependencies
Grouping is derived from what discovery found — blast radius and dependency order, not an architect’s recollection of the estate.
WAVES WITH ORDER
Adapt the plan to the inventory
Discovery keeps finding things. Each new resource, dependency or configuration difference re-shapes the waves before the next one is executed.
PLAN v2, v3, v4…
Adjust the destination to the requirement
Same source, different landing: managed or self-managed, instance family, region and residency, sizing to a budget. The target shape is a decision, not a default.
TARGET SPEC, AGREED
Migrate, wave by wave
Execution runs against the plan that was agreed, with per-resource state visible while it happens rather than at the end of the day.
PER-RESOURCE STATE
Name the failures, retry only those
Each failed resource carries the exact reason — quota, permission, collision, unsupported attribute. Re-attempt is scoped to those rows.
RETRY SCOPED TO FAILURES
03 feeds back into 02. Every resource discovery turns up late — a forgotten subnet, an undocumented dependency — rewrites the waves before the next one runs.
06 returns to 05, scoped. A retry re-attempts the failed resources only. What already landed is never touched twice.
06 — THE EXCEPTION LANE
The list of what can't move is the most valuable thing in the room.
Most migrations discover the manual tail in month three, after the price is fixed. Migration Factory names it in week one, in the console, with a reason per resource. Three things follow from that.
SCOPE PROTECTION
The manual tail is known before signature
The register is produced at discovery, so the work that cannot be automated is inside the scope conversation rather than discovered in month three against a fixed price.
BILLABLE SCOPE
An overrun becomes a work package
Each exception carries a reason and a disposition. That turns a class of work you would have absorbed into a priced line your customer can approve.
PRESALES ARTIFACT
Discovery, plan and register is the proposal
Three console outputs, co-branded, that a customer can read. Partners win on the specificity of the exception list more often than on the migration plan.
EXCEPTION REGISTER — SHAPE OF A ROW
How a move is sequenced
Stage 03 does not run the estate at once. Resources are grouped into waves by dependency and blast radius, so a failure takes down a known set of things. ILLUSTRATIVE
Edge and shared services
DNS, load balancers and the shared VPC. Nothing downstream depends on them being moved last.
- SCOPE
- 24 resources
- BLAST
- LOW
Stateless application tier
Compute and container workloads with no persistent state, redeployed against the landed network.
- SCOPE
- 61 resources
- BLAST
- MEDIUM
Data stores and cutover
Databases and object stores, with row and object counts checked against source before sign-off.
- SCOPE
- 18 resources
- BLAST
- HIGH
Not scheduled — exceptions
Oracle on RDS, a hand-written IAM policy set and an unsupported guest OS. Priced, not moved.
- SCOPE
- 9 resources
- BLAST
- N/A
Wave four is not scheduled. Those resources are in the exception register, priced as manual work, and the customer agreed to that before the first wave ran.
Two ways the same migration ends
Same estate, same team, same price. The difference is when the manual tail became visible.
WITHOUT A REGISTER
WITH THE REGISTER, WEEK ONE
What you hand your customer
Co-branded — your mark and CloudWorX on the same artifact. Generated from the console, not rewritten in a deck the night before.
Discovery report
The source estate as found — resources, dependencies, configuration.
Migration plan
Waves, sequence and blast radius, in an order the customer can approve.
Exception register
What cannot move, why, and what it will cost to handle by hand.
Validation reports
Resource and data validation, for the sign-off meeting.
Coverage matrix
Every pair, every status, one list. What is not supported sits at the same weight as what is.
No managed Oracle target on GCP. Lands in the exception register with a re-platform or Bare Metal Solution disposition.
Data model differs. Mapping is reviewed per table; secondary indexes may not carry over.
Runtime and trigger mapping is reviewed per function.
Policy semantics differ between the two models. Rewritten and reviewed by hand, then validated.
Listener rules and target groups are re-expressed; WAF rules are not carried.
Cluster is rebuilt and workloads redeployed. Node pool shapes are mapped, not copied.
Trigger bindings are re-expressed per function.
Identity model differs. Roles are redesigned and reviewed by hand.
Schema, partitioning and SQL dialect are reworked. Priced as a work package, not a move.
Concurrency and scaling behaviour differ; reviewed per service.
Query patterns are re-modelled per collection.
Reworked, not migrated. Enters the exception register as priced scope.
Managed-instance features do not all have a target. Checked per database at discovery.
Rebuilt by hand against the target identity model.
Feature parity is checked per database before the wave is planned.
Running a practice on it
A tenant per engagement
Every engagement runs in its own tenant with its own credentials and its own data. One customer’s estate is never visible from another’s console.
Repeatable across accounts
The second engagement starts from the same six stages as the first. What your team learned on one account is in the process, not in one architect’s head.
Less senior-architect time per migration
Discovery and planning come out of the console. Your most expensive people spend their hours on the exceptions, which is where judgement actually pays.
Faster time to proposal
Discovery and the register are the presales work. The gap between first conversation and priced proposal is a console run, not a workshop series.
Defensible artifacts
Every claim you make to your customer traces to something the console produced, with a record of when it was produced.
Three engagement types
Licensed per engagement. The unit is the engagement, whichever shape it takes.
Assessment
Discovery, migration plan and exception register only. No resources move. Your team walks the customer through what is there, what moves cleanly, and what does not.
ENDS WITH — A priced proposal
Partner-led migration
Your delivery team runs all six stages from the console. CloudWorX is on an escalation path and nothing more — the engagement, the plan and the customer are yours.
ENDS WITH — Validated estate and sign-off
Co-delivered migration
CloudWorX engineers work inside your engagement for the first waves, then hand the console over to your team for the rest. Used for a first engagement or an unusually complex estate.
ENDS WITH — Handover to your team
The questions we get asked first
Short answers. Every one of them is testable in a briefing.
We already have a migration methodology. Why would we take yours?
You keep yours. Migration Factory is where the six stages are executed and recorded — inventory, waves, moves, validation, exceptions. It replaces the spreadsheet and the shared drive, not the way you run an account.
Is Migration Factory a tool or a service?
A platform you operate. CloudWorX can work inside your first engagement if you want a co-delivered start, but the console is yours to run and the customer relationship stays yours.
What happens to the estate after the engagement closes?
Your engagement closes at validated sign-off. Artifacts and configuration state hand over to your team, or your customer’s own operations team, at that point.