Go-Live Readiness¶
Applies to: All subscriptions
Purpose¶
Decide, on evidence, whether to go live — then cut over, watch the first day, and hand over so the customer can operate without the implementer.
Audience¶
The project manager, with every stage owner. The decision is the project manager's; the evidence is everyone's.
Prerequisites¶
- Every stage gate 1 to 9 passed, signed and dated
- Production provider credentials in hand and tested
- A go-live date, and a decision point before it
- Support arrangements agreed and known to the customer
Steps¶
1. Confirm every gate¶
| Stage | Gate |
|---|---|
| 1 | Environments verified, including failure paths |
| 2 | Master data loaded and quality-checked |
| 3 | Users created and activated |
| 4 | Roles verified by testing; segregation decision recorded |
| 5 | Registrations, provider, routing and flags configured |
| 6 | e-Invoice proven, including failures |
| 7 | e-Way Bill proven, and the Part-B process defined |
| 8 | Integration proven, including recovery |
| 9 | Business sign-off, no blockers open |
A gate that was "mostly" passed was not passed. This is the last opportunity to be honest about it.
2. Work the readiness checklist¶
Compliance
| Check | Evidence |
|---|---|
| Statutory position confirmed in writing | From the tax lead |
| Reporting window understood | And the backlog approach agreed |
| Every registration onboarded, including dormant ones | The list reconciles to registration records |
| Provider production credentials tested | A successful connection test in production |
| Numbering unique per registration per year | Confirmed by the ERP team |
Technical
| Check | Evidence |
|---|---|
| Production verified end to end | Full post-installation verification |
| Cross-tenant isolation confirmed | Tested with two identities |
| Backup and restore proven | A restore performed |
| Monitoring live and alerting | An alert has actually fired |
| Certificates and credentials not near expiry | More than 30 days, with owners |
People
| Check | Evidence |
|---|---|
| Users trained on their own role | Demonstrated in stage 9 |
| Operations owner and deputy identified | Both can run the daily routine |
| Part-B owner identified | Named, with a defined point in dispatch |
| Exception owner identified | Named, with a daily process |
| Two administrators | At two individuals |
| Support path known | The customer knows how to raise a ticket |
Process
| Check | Evidence |
|---|---|
| Daily routine handed over | Documented and rehearsed |
| Escalation path agreed | Who, and when |
| Change control for configuration | Agreed |
| Rollback decision agreed | What would cause a return to the previous process |
3. Cut over¶
| # | Step | Note |
|---|---|---|
| 1 | Final verified backup | Before any change |
| 2 | Apply production provider credentials | The last configuration change, deliberately |
| 3 | Run the connection test | Against production. It must pass |
| 4 | Confirm no non-production environment holds production credentials | Verify by attempting a call, not by reading configuration |
| 5 | Enable the ERP feed | |
| 6 | Process one real document end to end, watched | Ingest, register, print, and confirm write-back reaches the ERP |
| 7 | Confirm the printed document | QR scans from paper |
| 8 | Release to users |
Step 6 is the moment go-live actually happens. Everything before it is preparation; everything after is operation.
4. Watch the first day¶
| Watch | Frequency |
|---|---|
| Documents arriving from each ERP | Hourly |
| Validation rejections | Hourly — the first day is when systemic faults appear |
| Registrations succeeding | Hourly |
| Write-back reaching the ERP | Hourly |
| Documents ageing towards the reporting window | Hourly |
| Errors and alerts | Continuously |
Have the implementation team available, and have the customer's team performing the checks. The purpose of the first day is to transfer operation, not to demonstrate it.
5. Watch the first cycle¶
Some problems appear only at month end, or on a weekly job. Keep heightened attention until the customer has been through one full business cycle, including a month end.
6. Hand over¶
| Deliverable | Detail |
|---|---|
| Configuration record | What is configured, and why |
| Baseline record | Version, migrations, verification results |
| Operational routines | Daily, weekly, monthly, year-end, with owners |
| Contact and escalation list | Current, using distribution lists |
| Known issues and accepted workarounds | From stage 9 |
| Open items with owners and dates | Nothing left implicit |
| Training record | Who was trained, on what |
Handover is a stage gate, not a formality. The customer demonstrates they can operate; they do not merely receive documents.
7. Revisit automatic registration¶
Once validation quality is proven over real volume — a few weeks, not a few days — revisit whether to enable automatic registration. It is a decision to take with evidence, not at go-live.
Validation¶
The go-live decision is yes when all of these are true. Any "no" moves the date.
| Check | Pass condition |
|---|---|
| Every gate passed | Signed and dated |
| Production credentials tested | In production |
| Environment separation verified | By attempting a call |
| One real document end to end | Watched, on the day |
| Print verified from paper | QR scans |
| Monitoring alerting | Tested by firing an alert |
| Owners named | Operations, deputy, Part-B, exceptions, administrators |
| Customer can operate | Demonstrated, not asserted |
| Support path known | Before it is needed |
| No blockers open | None |
Rollback¶
| Situation | Action |
|---|---|
| Cutover fails before the first real document | Revert credentials; disable the feed; no harm done |
| A systemic fault appears on day one | Stop the feed first, then diagnose. A stopped feed is recoverable |
| Documents registered with wrong data | Cannot be un-registered. Cancel within the window if appropriate; issue corrections. Consult the tax lead |
| The business cannot operate | Revert to the previous process while the fault is fixed. Documents already registered remain registered |
After the first real document is registered, go-live is not fully reversible. The government has it, the number is consumed, and no rollback returns that. This is why step 6 is watched and why every earlier stage runs on sandbox.
Common mistakes¶
| Mistake | Consequence | Avoid by |
|---|---|---|
| Going live with a gate "mostly" passed | The gap surfaces in production | Be honest at the decision point |
| Applying production credentials early | A test document permanently registered | Apply them at cutover, and only then |
| Not verifying environment separation after cutover | A non-production environment reaching production | Verify by attempting a call |
| The consultant performing the first-day checks | The customer cannot do them on day two | The customer performs; you observe |
| Ending support at go-live | The first month-end has nobody | Stay through one full cycle |
| Enabling automatic registration at go-live | Rejections at volume on day one | Revisit with evidence, weeks later |
| Handover as a document transfer | Knowledge that never lands | Handover is a demonstration |
| No named exception owner | Rejections accumulate to a deadline | Name one before go-live |
Troubleshooting¶
| Symptom | Cause | Action |
|---|---|---|
| Production connection test fails | Credentials not activated, or the egress address not allow-listed for production | Confirm with the provider. Do not proceed |
| The first document quarantines | A configuration or data difference between environments | Compare configuration; do not force it through |
| Rejections at volume on day one | A systemic fault | Stop the feed, diagnose, fix, resume |
| Write-back does not reach the ERP | Flag, subscription, or consumer | Check in that order |
| Users cannot sign in on day one | Mail, or access never verified in production | Check mail first |
| A document reached the government with wrong data | A mapping fault that survived testing | It cannot be un-registered. Consult the tax lead |
Related Articles¶
- Implementation Programme — the whole sequence
- Post-Installation Verification
- Daily Checks — what happens next
- Operations Guide