A repository, a runbook, and a final walkthrough can all be delivered on schedule while the client remains unable to operate the solution.
The code may live in the right account, but only the consultant understands the architecture decisions. A dashboard may exist, but nobody owns the alert. An evaluation set may be attached, but the receiving team cannot explain what failure requires a rollback. Credentials may have been transferred while the provider still holds privileged access “just in case.”
That is document delivery, not capability transfer.
Transfer is an architecture and operating decision made at intake. It cannot be assembled at the end from whatever artifacts survived the build. A credible independent FDE plans where the solution, evidence, decisions, access, operations, and working knowledge will land before production access is granted.
Guidance boundaries make ownership visible
Vendor programs help show why the boundary matters. Microsoft currently describes FastTrack as guidance and identifies hands-on implementation and fee-added services as work that may sit with partners. Program scope and eligibility can change, so buyers should verify the current pages and their agreement. The durable operating lesson is narrower: when vendor guidance stops, implementation ownership does not disappear. It must be assigned.
Factory's AI Engineer session adds a technical view. The speaker describes delivery around a customer-owned harness and environments that may include restricted or air-gapped deployments. That is an attributed account of one vendor's model, not a general requirement or endorsement. It illustrates how architecture can support or obstruct transfer.
An independent FDE should be explicit about the receiving system on the other side of the engagement.
Six objects need a destination
The solution includes source, configuration, build and deployment instructions, dependencies, environments, and accounts. “The client owns the code” is incomplete if the client cannot reproduce or release it through an approved path.
The evidence includes acceptance scenarios, evaluation definitions, results, limitations, known failures, and the conditions under which the evidence was produced. A screenshot of a successful demo cannot support a future change decision.
The decisions include material architecture choices, rejected alternatives, permission boundaries, data handling, dependencies, accepted debt, and reversal triggers. Without the reasoning, a receiving team either preserves obsolete choices or unknowingly reopens them.
The access includes human accounts, service identities, secrets, repositories, vendor seats, logs, and production privileges. It needs named owners, expiry, rotation or revocation, and evidence that provider access was removed when no longer authorized.
The operations cover health signals, alerts, routine changes, rollback, fallback, incident intake, support, data disposition, cost review, and maintenance. Each needs a client owner rather than a paragraph that assumes one.
The capability is the receiving team's ability to use, review, change, recover, and govern the system. It is the object most often assumed and least often demonstrated.
Make the receiving model a day-one decision
Intake should name the business, product, technical, security or privacy, and deliverable owners. One person may cover multiple roles, but authority must be visible. The same intake should name the intended operator and decide whether any residual provider support is expected. If support is needed, its scope and duration should be explicit rather than emerging after handoff.
Accounts and repositories should be created in the intended ownership model. Production access should be narrow, time-bound, approved, and removable. Secrets belong in the client's approved system. Data purpose, retention, export, and deletion need owners before real data is introduced.
Architecture choices should consider who will operate them. A technically elegant component is a poor transfer choice if the receiving team cannot support it and no durable support model exists. That does not mean choosing only familiar technology. It means recording the cost of novelty and assigning the capability gap.
These decisions may feel administrative early in a build. They are cheaper than reconstructing ownership during closeout.
Build the handoff as the system evolves
When the team makes a material decision, record the context, options, consequences, evidence, and reversal trigger. Version evaluations with their examples, rubric, configuration, and limitations. Give every new dependency an owner, support path, data behavior, and failure mode. When a demonstration reveals an exception, update both the backlog and the operating procedure.
The receiving team should also take on more of the work over time. Early on, its members learn by watching. As the deployment matures, they should make decisions, run routine scenarios, interpret evidence, and exercise failure paths. A final lecture cannot replace that progression.
Reverse-shadow is the transfer evidence
A practical sequence moves through five states:
- Explain: The FDE walks through architecture, controls, evidence, decisions, and runbook.
- Shadow: The receiving team observes routine operation and change.
- Reverse-shadow: The receiving team performs the work while the FDE observes.
- Exercise: The team handles a controlled failure, fallback, rollback, or access-revocation scenario in an authorized environment.
- Own: Named client owners accept responsibility, while remaining gaps receive an owner, date, and disposition.
Reverse-shadow changes the evidence. The question is no longer whether a document exists, but whether the receiving team can use it. A meaningful exit test includes the unhappy path: identify a low-quality or unsafe output, disable the affected path, interpret quality evidence, recover from a dependency failure, and remove an identity that no longer needs access.
Passing those scenarios does not guarantee that future support will never be needed. Models, vendors, workflows, data, and staff will change. Residual support may be sensible, but “call the original builder forever” is not an operating model.
Put transfer into acceptance
If transfer matters, it belongs in the first statement of work and acceptance design. Name the artifacts, owners, scenarios, access disposition, training evidence, known-issue treatment, and support boundary. Decide what “ready with gaps” means and who may accept those gaps.
This protects both parties. The client can evaluate whether it is acquiring capability rather than a collection of files. The independent FDE can finish without pretending to own operations that were never assigned.
The cleanest handoff begins before the first production credential exists. Put transfer criteria beside deployment criteria, then build toward both.
Sources and evidence notes
- Microsoft Agent 365 FastTrack and Microsoft FastTrack: official, current program-boundary context; scope and eligibility may change.
- Factory FDE session: attributed practitioner description of a customer-owned harness and restricted environments.
- Caylent enterprise deployment session: attributed practitioner context on production deployment, evaluation, access, and user context.
The six transfer objects and exit test are Scott's proposed operating model. They do not imply endorsement by the cited providers or guarantee independence from all future support.