Cloud Migration

Cloud Migration Services That Are Scoped Around Day 90, Not Cutover

A cloud migration is one of the few things you can buy where nothing about the purchase is visible on the day you make it. The servers come up. The applications respond. Everybody goes home. Whether you bought a good migration or an expensive relocation is a question that gets answered somewhere around day 90, long after the project closed and the team that ran it moved on.

That is not a scare story about cutover risk. Cutover is the solved part — data integrity, application compatibility, coordination windows are all well-understood problems with well-understood answers. The unsolved part is the ninety days afterwards, when the environment stops resembling the thing that was planned and starts resembling whatever your teams do to it.

Facet Interactive delivers cloud migration services across AWS, Azure and GCP as measured Agent Loops — assess, migrate in waves, validate against a real observation window, then operate. We are unusually confident about the day-90 half, and the reason is that it is the half we have run on ourselves thousands of times.

Our own environment is migrated continuously, so day 90 is the part we have the most practice at

Facet's delivery — engineering, research, quality review and reporting — runs through Agent Loops under human command. A consequence of that is not obvious until you have lived with it: our own operating environment is under continuous change, and every one of those changes is a miniature migration. Something moves, a cutover happens, and then there is a window in which you find out whether it actually settled.

We have far more day-90 experience than day-1 experience. A firm that sells migrations as projects runs cutover constantly and observation almost never, because they are gone before the window closes. Our own stack gives us the opposite ratio. The failures we know best are the ones that show up at week six, and those are the failures that cost money.
We learned that the wave is the unit, the hard way. When a change goes wrong in a system that runs on agents, it goes wrong at volume and it goes wrong fast. Rollback windows and staged waves are not a client-facing methodology we wrote down; they are the discipline that keeps our own delivery from breaking in a way we cannot undo.
We learned which day-1 decisions are guesses. Rightsizing at migration time, reserved commitments bought before real usage exists, thresholds set against a workload that has not run yet — all of those are estimates dressed as configuration. We treat them as provisional on our own systems, and we treat them as provisional on yours.

The longer account of how the operation is structured is in We Run Our Own Business on Agents. The relevant part here is narrow: we are not describing an observation window we intend to invent for your project.

Why most cloud migrations disappoint after cutover, not during it

A cloud environment on day one looks nothing like the same environment at day 90, and almost none of the difference was in the plan.

Resources appear without tags. Teams provision the moment they have access. Within a quarter the bill contains line items nobody can attribute, and the cost model the migration was justified on stops being checkable.
Rightsizing decisions made at migration time turn out to be wrong. You sized against a workload profile from the old architecture, which is the only data you had. The real profile arrives later.
Reserved commitments get bought too early. Committing to a year of capacity before the usage pattern is understood converts a flexible cost into a fixed one, in the wrong direction.
Security groups that fit the old architecture do not map cleanly. They get widened to make something work and rarely narrowed afterwards.

None of that is failure at cutover. It is the absence of an operating model, and a migration without one is a project with an expiry date.

Estimate your own exposure before you talk to anyone. If you are already partly in the cloud, count the resources in that footprint nobody can name an owner for. Those are the ones that will be migrated twice — once into the new environment, and once more when somebody finally works out what they were. That count, not an industry average, is the honest input to how much assessment work is worth buying.

How could AI agents run your cloud migration? Book the migration assessment — one session, fixed scope, against your real environment. You leave with an inventory and dependency map, a recommended migration path across AWS, Azure or GCP, a wave schedule, and a written statement of what the operating model needs to look like after go-live.

How Facet runs a migration

Four phases, each with defined outputs and a validation gate. Agents carry the continuous work inside every phase; people own every decision between them.

Phase 1 — Assess. We inventory the environment: infrastructure, dependencies, data flows, licensing and cost structure. The output is a migration readiness map that becomes the baseline every later phase is measured against. We identify what moves as-is, what needs refactoring, and what is better rebuilt cloud-native — and we model what the equivalent footprint costs on each candidate platform, from your actual usage rather than a sizing template.

Phase 2 — Migrate in waves. Workloads move in prioritized waves. Low-risk, low-dependency services go first and establish the monitoring baselines that the higher-stakes systems are later judged against. Each wave carries a defined rollback window and a validation checklist. When something unexpected surfaces — and something always does — it surfaces at the scale of one workload rather than the whole organization.

Phase 3 — Validate against a real window. After each wave, agents run continuous validation: application health, cost against projection, security posture and performance against pre-migration baselines. Nothing is signed off on the day it moves. Sign-off happens after a stated observation window, because the defects that matter here are the ones that need time to appear.

Phase 4 — Operate. The migration project ends and the operating loops stay on: cost attribution, drift detection, availability. This is where a migration either becomes durable or quietly reverts, and it is why the operating scope is agreed at the start rather than sold as an add-on when the project closes.

What the loop actually does

Inside those phases, a specific set of passes is agent-carried. Each is continuous, mechanically checkable against a stated baseline, and finds nothing most of the time — which is exactly why a human team stops running them around week four, right when the findings start to matter.

Compare running cost against the migration projection, daily. The number the migration was justified on is checked against the number the environment is actually producing, every day, while the variance is still small enough to explain.
Watch performance against the pre-migration baseline. Latency, error rates and throughput measured against what the workload did before it moved — the only comparison that answers "did this actually work?"
Detect configuration drift from the migrated state. Security groups, roles, policies and tags compared against what was signed off at the end of each wave, with the specific change and its timestamp attached.
Reconcile what was planned against what is running. Wave by wave, the inventory from the assessment is checked against reality, so a workload that was supposed to be retired and is still running surfaces as a finding rather than as a line on next year's invoice.
Track the provisional decisions. Rightsizing calls and commitment purchases are logged as estimates with a review date, and re-examined against real usage once it exists.

What a person still decides

The loop produces evidence. It does not sign anything off.

Whether a wave has actually settled. The data says the variance is within range. Whether that means stable or means the traffic has not arrived yet is a judgment about your business calendar, and a named Facet engineer makes it.
What the migration path is. In-place, rebuild, hybrid, headless, multi-cloud — that is a decision about your licensing, your team's operational familiarity, your data residency obligations and what you intend to build next. It is not a scoring exercise.
Which workloads move first, and which never move. Sequencing is a risk decision about your customers. Some workloads are cheaper and safer where they are, and saying so is part of the assessment.
When a provisional decision becomes permanent. Converting a rightsizing estimate or a reserved commitment into a standing choice is a money decision with a term attached. A person makes it, with the usage data in front of them.
When to stop. A partially migrated estate is sometimes the right end state. Finishing for the sake of finishing is how migrations lose the argument they started with.

Platform-agnostic across AWS, Azure and GCP

Facet works across AWS, Azure and GCP with no platform partnerships creating an incentive to recommend one over another. The right platform depends on your existing licensing, your team's operational familiarity, your data residency requirements and your application architecture.

Frequently the right answer is more than one: some workloads optimized for AWS, Microsoft 365 integration running through Azure, analytics workloads on GCP. We scope around workload fit. The platform changes; the method — documented plan, wave execution, rollback windows, a stated observation window, ongoing operating coverage — does not.

Where cloud migration goes next

A ladder, not a bundle. A migration that lands well and goes no further is a complete outcome.

Cloud Services — the governance layer for the environment you just landed in: provisioning intake, tagging and ownership discipline, baseline security applied at creation, so the new estate does not accumulate the same debt the old one did.
Cloud Management & Monitoring — the ongoing watch and the after-hours response, for when the observation window ends and the environment simply has to keep running.
IT Managed Services — the endpoint, identity and helpdesk surface around the migrated infrastructure.
Agentic Engineering and AI Managed Services — the layers above the infrastructure, for when the migrated environment is the foundation for agents running operational work rather than just hosting applications. The Agentic Operating System explainer covers the shape while those service pages are in production.

Why Facet

Facet Interactive has been a boutique systems integrator since 2014, and CIOReview named us a Top 10 Digital Transformation Services Company in 2021. Our team of 40 spans 9 timezones and 6 continents, backed by a network of 500+ open-source, cloud and IT specialists.

Distributed staffing is load-bearing for this specific service rather than a general credential. Cutover windows run overnight and observation windows run continuously; both are staffing problems before they are engineering problems, and a firm keeping one office's hours solves them by asking someone to stay up.

You will not find an industry percentage anywhere on this page. Your environment's architecture, configuration age, licensing structure and spend level determine what a migration recovers and on what timeline. The assessment produces your figure instead of borrowing somebody else's.

Start with a migration assessment

How could AI agents run your cloud migration? Book the migration assessment — one session, fixed scope, against your real environment. We inventory what you have, map the dependencies, recommend a path across AWS, Azure or GCP, produce a wave schedule with rollback windows, and state plainly what the operating model has to look like after go-live. You leave with the documented plan whether you engage Facet for the migration or not.

Sometimes the honest finding is that you should not move. If the assessment shows a stable workload whose economics are better where it is, or a licensing position that makes the move expensive for years, the document will say so — and that answer costs us the migration. We would rather lose it there than run a project whose business case stops holding around month four.

How pricing works. Migration engagements are fixed-fee, scoped after the assessment, and priced on environment complexity, the number of platforms involved, the waves required and how much post-migration operating coverage you want. Facet's project range starts at $6,000. There is no standard price list, because a single-provider workload move and a multi-platform program are not the same work.

Buy the room that will be there on day 90

Most purchases can be judged when you make them. You can look at a website, use a piece of software, read a report. A migration gives you none of that. On the day it completes, a good migration and a bad one are indistinguishable — both are an environment that is up.

So the thing you are actually choosing is who is in the room when the evidence finally arrives. Not the cutover team. The people who are still engaged at week six, when the cost variance has drifted, the rightsizing call turns out to have been optimistic, and a security group has been widened by someone with a good reason. That is when a migration is either corrected or quietly accepted, and it is the one moment a project-shaped engagement is structurally unable to be present for.

Ask any firm you are considering one question: what happens on day 90, and who specifically is doing it? The answer separates a migration from a relocation more reliably than any part of the plan you will be shown.