The Deadline
How long does it actually take to move off cloud AI? A realistic timeline
Not a weekend, and not two years either. A practical, phase-by-phase view of what moving to a sovereign, self-owned AI setup actually involves, so the schedule can be built on fact rather than guesswork.
The short answer
A realistic migration from cloud AI to a sovereign, self-owned setup runs in phases rather than a single event: evaluation and hardware sizing (four to eight weeks), procurement and setup (four to twelve weeks depending on hardware lead times), a parallel-running pilot alongside the existing cloud tool (four to eight weeks), and a phased cutover by team or workload rather than all at once (eight to twelve weeks). Most organisations should plan for a six to nine month window from first evaluation to full cutover, not because the technology is slow, but because doing it properly means testing before committing, not committing before testing.
One of the reasons the sovereignty decision gets left undated is that nobody has a clear picture of what the project actually involves. Without a shape, it is easy to imagine either extreme, a weekend project or a two-year ordeal, and both imagined versions are wrong in ways that make planning harder, not easier.
The four phases
1. Evaluation and hardware sizing (four to eight weeks). Establishing what the organisation actually needs: which workloads move first, what hardware they require (a text-focused assistant needs far less than high-volume document reading), and what a realistic total cost of ownership looks like against the current cloud spend.
2. Procurement and setup (four to twelve weeks). This range varies mainly on hardware lead times, which is why it should start as early as possible, ideally overlapping with the evaluation phase rather than waiting for it to finish. Software setup, in contrast, is usually the faster half of this phase.
3. Parallel-running pilot (four to eight weeks). The sovereign setup runs alongside the existing cloud tool on real workloads, not synthetic tests, for long enough to surface the problems that only show up under actual use. This is the phase organisations are most tempted to skip, and the one whose absence causes the most expensive delays later.
4. Phased cutover (eight to twelve weeks). Moving team by team or workload by workload rather than flipping a single switch, so that a problem in one area does not become an organisation-wide outage, and so that lessons from the first team moved improve the process for the next.
The pilot phase is the one organisations are most tempted to skip, and the one that causes the most expensive delays when they do.
The realistic total: six to nine months
Add the phases up, allowing for some overlap between evaluation and early procurement, and a genuine, properly tested migration runs six to nine months from first evaluation to full cutover. That is not a sign of a slow or difficult technology. It is what "tested before committed, not committed before tested" actually looks like on a calendar, and it is a schedule that fits comfortably inside the renewal-date planning window described in our companion piece, if the evaluation starts early enough.
What shortens it, and what doesn't
- Shortens it: ordering hardware early, in parallel with evaluation rather than after it.
- Shortens it: starting with the smallest, lowest-risk workload as the pilot, not the most critical one.
- Does not shorten it, and should not be attempted: skipping the parallel pilot phase to save four to eight weeks. This is consistently where rushed migrations lose far more time than they saved.
Putting this on the calendar
A six-to-nine-month timeline is not a reason to wait, it is a reason to start counting backward now from whatever real deadline applies, a contract renewal, a board cycle, or a regulatory date such as 2 December 2027. Knowing the real shape of the project is what makes it possible to actually schedule it, instead of leaving it as an intention with no date attached.
Frequently asked
- Can this be done faster if the organisation is small?
- Somewhat, since a smaller organisation has fewer workloads and teams to move in sequence, but the phases themselves do not compress much: hardware still has to be sized and delivered, a pilot still needs to run long enough to catch real problems, and rushing the pilot phase is the single most common cause of a migration that has to be redone.
- What is the biggest cause of delay?
- Skipping the parallel-running pilot phase to save time. Organisations that move straight from evaluation to full cutover, without running the sovereign setup alongside the existing tool for real workloads first, are the ones that discover a critical gap after they have already committed, and end up losing far more time reversing course than the pilot phase would have cost.
- Does the six to nine month estimate include hardware delivery?
- Yes, and hardware lead time is one of the more variable parts of the schedule, which is exactly why it belongs in the plan from day one rather than being discovered partway through procurement. Ordering hardware early, in parallel with the evaluation phase rather than after it, is one of the simplest ways to shorten the overall timeline without cutting any real corner.
