FIELD · Customer delivery · 4 min read
Moving a service into customer ownership
Transfer deployment, credentials, recovery, monitoring and support ownership.
Arunank Sharan · Kuzushi Labs ·
In this article
This worked application uses explicit planning assumptions to demonstrate FIELD. Quantities below are inputs, calculated implications or proposed targets; they are not reported customer results. The engagement decision remains conditional on the evidence described.
Planning basis and engagement boundary
| Item | Basis for this application |
|---|---|
| Demand and context | Six-week transition; 99.9% service target over a 30-day window |
| First delivery boundary | Transfer deployment, credentials, recovery, monitoring and support ownership |
| Acceptance to agree and test | Customer operator completes the agreed restore and reconciliation exercise |
| Exclusion or constraint | Feature expansion is separated from the ownership transition. |
F — Frame the outcome
Transfer a successful pilot to customer ownership in six weeks while preserving the agreed successful-request SLO and a reversible migration.
Value measure: Unassisted recovery, migration error rate and time/cost of ongoing manual support.
I — Investigate the workflow
Inventory personal accounts, manual fixes, hidden dependencies, credentials and who can actually restore the complete system.
First evidence task: Restore the customer deployment and switch back across an index schema change.
E — Engineer the solution
Use full-bundle versioning, dual-running capacity, schema/data compatibility and recovery tests; application rollback alone is insufficient.
The implementation assessment below makes the authority, workload, resource and failure assumptions concrete. Its numbers are calculations from the stated scenario, not a vendor performance guarantee.
Inventory
Identify accounts, credentials, data, models, indexes, manual fixes, release artifacts, external quotas, network dependencies, monitoring and ownership. Establish what the 99.9% successful-request SLO counts; task quality remains separately evaluated.
Migration plan
Create customer-owned environments and infrastructure/configuration manifests. Backfill a versioned store/index, apply deltas, validate source completeness and permissions, then shadow traffic. Canary a cohort, expand gradually and retain a supported rollback path. Use one authoritative write owner or explicit deduplication/reconciliation during dual-running; uncontrolled dual writes are not a migration strategy.
Sizing
If old and new indexes each occupy 200GB, transition needs at least 400GB for the two live copies, plus build workspace, snapshots and growth. If normal application load is 2c and each worker safely supplies c, one-node-loss reserve requires three ready workers; keeping both complete old/new fleets temporarily doubles that application reservation. Shared DB/quota capacity may still be the limiting resource.
Schema perturbation
Expand the schema compatibly, backfill and validate before switching readers. If the new index format is incompatible, keep the old version updated during the rollback window or provide a tested reverse/rebuild path. Reverting code alone cannot undo data already rewritten into an unsupported representation.
Handover evidence
A customer engineer deploys from the manifest, rotates a noncompromised test credential, diagnoses a seeded fault and restores a backup using the runbook. Supply dashboards, incident escalation, cost alerts, support scope, user training and an owner for model/evaluation updates. Measure observed restore/recovery time separately from targets.
Gate
Expand only after both technical acceptance and workflow adoption are established. Stop dual-running once rollback conditions expire and reconciliation is complete, preventing permanent doubled cost and ambiguous ownership.
L — Launch with evidence
Canary the customer-owned deployment, test rollback across state/index versions and agree when dual-running ends. Measure successful requests with a defined denominator.
Critical decision condition: Missing customer-owned recovery access or incompatible rollback blocks handover.
Attach raw artifacts, the tested configuration, population, denominator, date and limitations to the release record. Missing or stale evidence holds the dependent decision. A favorable value forecast cannot offset a failed critical condition.
D — Develop ownership and reuse
Have the customer operator perform recovery while the delivery engineer observes. Accept ownership only when critical dependencies and support responsibilities are transferred.
Candidate reusable asset: Full-system release manifest and ownership rehearsal.
Commercial decision and next commitment
Accountable decision owner: Customer service owner.
The initial commitment is the bounded journey above, with the stated exclusions. Confirm access, customer staffing and acceptance ownership during discovery; price and schedule unresolved dependencies explicitly. A new source, tenant class, language, action or operating envelope requires an impact review rather than silent scope growth.
Approve only the next exposure level supported by the evidence. The next useful investment is: restore the customer deployment and switch back across an index schema change.
Method and references
Apply the FIELD method, economic model and evidence rules. Methodological and technical influences are listed in the source register.