Lesson 5 of 5
Go-live evidence and handover
9 min
Listen to this lesson
A partner is live when two things are true: the evidence shows it works, and someone other than the project team can run it. The go-live evidence pack answers the first; the handover answers the second. Both are short documents if the earlier phases were done well, and long arguments if they weren't.
The evidence pack
- AgreementsSigned mapping spec with version, partner's implementation guide version, partner certification e-mail or letter.
- Test resultsTest summary by layer, every rule ID with a passed test, defect log with closures, the end-to-end confirmation from the partner.
- Pilot resultsDaily reconciliations, clean-day count against the criteria, list of document types exercised in production.
- ConfigurationProduction TPM agreement active, Partner Directory entries visible, number ranges set, VOE2 and VOE4 entries and customer-material records in CMP.
- SecurityCertificates in place with expiry dates and the renewal contact on both sides.
- OperationsRunbook, alert routing, support roles assigned, hypercare plan.
Production checks before the first real order
Test environments prove the logic; production has its own configuration. Before full go-live Contoso runs a short production connectivity check with Northern Plains: a test-flagged interchange (ISA15 = T) to confirm the production endpoint, certificates and MDN, with the agreement set not to pass test interchanges to the target system. Then it confirms production master data: the customer, all 11 depot ship-tos, the partner conversion entries, customer-material records and the contract price. A missing VOE4 entry in CMP is the classic first-day failure.
The runbook
Support needs one page per partner they can use without a developer. Contoso's Northern Plains page lists: identifiers (ZZ NPCOACHEDI, AS2 ID NPCL-AS2), the agreement name, documents and directions, expected volume and the Monday peak, cut-off time, certificate expiry and renewal contacts, the daily reconciliation steps, the common errors and their first checks (unknown depot, unknown part, overdue 997, negative MDN), when to restart or retry in the B2B monitor and who may cancel, and escalation contacts on both sides with their hours.
Certificates and records after go-live
Two items outlive the project and are easy to forget. Certificates expire, usually after one to three years; record both sides' expiry dates in the runbook, put a reminder 60 days before each, and plan the renewal like a small change with its own connectivity test. The evidence pack also has a life after go-live: auditors and the partner may ask for it months later, so store it with the partner's profile documents, under the retention rules Contoso applies to other test evidence, rather than in a project folder that will be archived.
Hypercare and handover
Hypercare is a fixed period, two weeks for Northern Plains, in which the project team and support work side by side. The support desk handles every incident with a project member watching, so the runbook is tested on real cases. At the end, support signs the handover: they have used the runbook, they know the escalation routes, and the open items list is agreed. Developers keep design rights only in CMC_DEV; changes move CMC_DEV → CMC_TEST → CMC_PROD with Luis as release manager.
- Is every pilot criterion met and documented?Yes → next question · No → extend the pilot with a dated plan
- Is production configuration verified, including master data?Yes → next question · No → fix and recheck before switching
- Has support used the runbook on real cases?Yes → next question · No → keep hypercare running
- Has the partner agreed the switch date in writing?Yes → full go-live and handover · No → agree it before switching
Close the onboarding with a short retrospective. What took longest, which assumptions were wrong, which questionnaire question was missing? Contoso adds one finding per partner to its template: after Northern Plains, the questionnaire now asks for the full list of ship-to locations with their codes in the first week, because depot codes caused half of the test defects.
What would you do?
On Northern Plains' first full day, three orders from a newly opened depot D12 fail in status 51. The depot wasn't in the questionnaire. What should the support desk do, following the runbook?
- The evidence pack covers agreements, test and pilot results, production configuration, security and operations.
- Prove production connectivity with a test-flagged interchange and check production master data before the first real order.
- Write a one-page runbook per partner and test it during a fixed hypercare period.
- Hand over to support formally and feed lessons back into the onboarding template.
Check your understanding · not graded
Lesson check
1. How does Contoso prove production connectivity before the first real Northern Plains order?
2. What is the classic first-day failure for a new inbound EDI partner?
3. What should happen at the end of hypercare?
4. Why add one retrospective finding to the onboarding template after each partner?