Anatomy of a Two-Week Go-Live

Two Weeks Is a Design Constraint, Not a Sprint

When enterprise buyers hear "your stack is up and running in two weeks," they translate it into one of two things: a demo environment dressed up as production, or a team of consultants working nights. Both translations come from the same experience — decades of ERP and CRM implementations where migration was a services engagement layered on top of the product, staffed by people who had never seen your systems before and billed by the hour to learn them.

Own360 makes a different bet. Migration is not something done to the platform; it is a capability of the platform. OwnETL replicates and reconciles data as a product function. Coding agents and browser agents re-implement business logic as a product function. The discovery workshop that decides how each system moves is a fixed, structured exercise with defined outputs — not an open-ended assessment phase. When those pieces are product, the timeline stops being a function of consultant availability and becomes a function of architecture.

One caveat before the walkthrough, stated plainly because it matters: what follows describes the standard deployment plan — the sequence Own360 engagements are structured around — not a universal guarantee. Estates with hundreds of systems, unusual regulatory sign-off chains, or hardware procurement on the critical path will stretch individual phases. The point of this post is not that every organization hits day 14; it is that the plan is concrete enough to be walked through hour by hour, which is precisely what a services-led migration never is.

Days 1–2: The Workshop That Decides Everything

The engagement does not start with software. It starts with a technical discovery workshop whose output is a decision, per system, on two independent tracks.

The first track is business logic. For each system being replaced, the workshop settles how its operational behavior moves: code-led, where source access exists and coding agents re-implement the workflows directly from the codebase; UI-led, where a SaaS vendor controls the backend and browser agents learn the flows through the interface instead, with no backend access required; or workshop-led, where the logic lives in people rather than code and structured discovery turns tribal knowledge into a migration blueprint.

The second track is data. Again per system: replicate, syncing the dataset into OwnData; virtualise, querying it in place so nothing moves — the right answer for residency-constrained or regulated sources; or bridge, letting existing APIs feed OwnFlow during the transition so the estate keeps functioning while it changes underneath.

The critical property is independence. A SaaS CRM might get UI-led logic and replicated data. A regulated warehouse might get workshop-led discovery and virtualised access, with not a single record copied. The workshop does not produce a philosophy; it produces a table — one row per system, one decision pair per row — plus a sequenced roadmap and a risk register. We covered the framework itself in depth in our migration walkthrough; here the point is timing. Because the framework is fixed, the workshop takes two days, not two months.

Days 3–7: Environment Up, First Module Deployed, Data Moving

With the decision table in hand, the platform goes wherever the workshop said it should: a cloud VPC, on-premise on bare metal, VMware or k3s — fully air-gapped if the environment demands it — or a managed sovereign deployment. Encryption at rest is AES-256, transport is TLS 1.3, and keys are customer-controlled from the first boot. Identity comes up first: OwnCentral wires into the existing SSO, and roles for both people and agents are mapped before any business data arrives.

This is the Land phase, and Land has a rule: deploy where the pain is highest. Not the easiest module, not the flagship one — the one whose current system is causing the most operational damage. If procurement approvals are the daily fire, the first module is procurement. A first module chosen for pain does two things a pilot chosen for safety never does: it recruits its own champions, and it stress-tests the migration machinery against real complexity immediately.

In parallel, OwnETL begins the data track. For replicated systems, initial sync starts on day 3 and reconciliation runs continuously from that moment on — this is not a one-shot export but a live pipeline that keeps source and target aligned for the entire transition. Virtualised sources get their query layers stood up; bridged systems get their API connections into OwnFlow. By the end of day 7 there is a running production environment, a governed identity fabric, and data flowing under reconciliation.

Days 8–12: Re-Implementing Logic, Validating Row by Row

The middle stretch is where migrations traditionally go dark — the phase where consultants disappear into "configuration" and status meetings replace evidence. In the Own360 plan it is the most observable phase, because both tracks produce checkable artifacts daily.

On the logic track, agents do the re-implementation the workshop scoped. Code-led systems have their workflows extracted from source and rebuilt in the matching OwnApp; UI-led systems have the flows browser agents learned rendered as native configuration; workshop-led blueprints get built out with the process owners reviewing each flow against how the work is actually done. Every re-implemented flow is exercised against real cases from the old system: same input, both systems, compare outputs.

On the data track, reconciliation gets adversarial. OwnETL verifies migrated data row by row against the source — record counts are a vanity metric; field-level comparison is the standard. Discrepancies surface as a worklist, not a surprise, and each one is either a mapping fix or a data-quality issue the old system had been silently tolerating. Organizations are routinely more surprised by what this phase reveals about their existing data than by anything the new platform does.

A migration you can check row by row is a project. A migration you have to take on faith is a hostage situation.

Days 13–14: First Teams Live — in Parallel

On day 13, the first teams start doing real work in the first module. Not user acceptance theatre with synthetic cases — actual daily operations. The safety mechanism is the parallel run: the old system remains fully authoritative while the new one handles the same work alongside it, and OwnETL's continuous reconciliation means every divergence between the two is detected as it happens rather than discovered at quarter close.

This is what makes "zero downtime" a mechanical claim instead of a marketing one. There is no cutover cliff in week 2 because there is no cutover in week 2. There is a second system doing the work correctly, provably, next to the first — and authority shifts only when the evidence says it should.

Weeks 3–8: From First Module to Full Estate

What follows is repetition, not invention. The machinery proven on the first module — deploy, replicate, re-implement, validate, run in parallel — is applied to the next system on the workshop's sequenced roadmap, then the next. Each wave is faster than the last because the identity fabric, the deployment, and the reconciliation pipelines already exist; each new module lands on a control plane that is already governing the previous ones, and cross-app workflows begin composing across modules as they arrive.

By week 8, in the standard plan, the full estate has cut over: authority for each system has shifted to Own360 the same way the first module's did — gradually, under reconciliation, with the parallel run absorbing the risk that a big-bang cutover concentrates into one terrifying weekend.

Why the Old System Stays Read-Only for 90 Days

Cutover does not mean deletion. After authority shifts, the old system stays available in read-only mode for 90 days. This is not sentimentality; it is engineering discipline with three specific functions. First, it is the reference of last resort: if any output is questioned in the first quarter, the original source is still there to check against. Second, it de-risks the long tail — quarterly and annual processes that never executed during the migration window get their first run with the old system still consultable. Third, it converts rollback from an emergency procedure into a standing option nobody has to use, which changes how calmly everyone behaves.

What the Two Weeks Actually Prove

The purpose of the Land phase is not speed for its own sake. It is that by day 14 every mechanism the full migration depends on — the workshop's decisions, OwnETL's reconciliation, agent-driven re-implementation, the parallel run — has been exercised end to end on a real module with real users. Everything after that is the same machinery applied more times. That is the honest content of "live in two weeks": not a miracle, and not a promise that every estate is average, but a plan specific enough to be audited before you commit — and to be checked against reality every single day after you do.

The two-week go-live is not the impressive part. The impressive part is that weeks three through eight are boring.