State migration is the kind of work where the plan matters more than the execution. We assess read-only, write the plan, and run it alongside your team — on your infrastructure, under your credentials.
A single state has become large enough that every plan is slow and every apply is frightening. Splitting it means moving resources between states without destroying and recreating them.
Local state, or a backend that no longer fits — moving to S3, GCS, Azure Blob or Terraform Cloud, with locking and versioning set up properly on the way in.
A merger, an acquisition, or a repo split that left resources spread across states that disagree about who owns what.
Live infrastructure that no state claims, which has to be imported before it can be managed rather than recreated underneath a running service.
Scope, timeline and price are set at the scoping call, against your actual state — there is no useful fixed answer before someone has looked at it.
Twenty minutes is usually enough to work out whether this is a week of work or an afternoon, and we would rather say the second one now.
This is consulting work, not software — it is a separate engagement fromCloudkeel-DD, which you caninstall yourself without talking to anyone. We are pre-launch: no customers yet, and no SOC 2.