What to do post Go-Live?

Go-live is the moment the new system becomes the real one. Handled well, it's an anticlimax - things simply work. Handled badly, it's where months of effort unravel in the first chaotic week. The difference is preparation and a realistic plan for the period right after.

Going live: phased or all at once

There are two broad approaches, and the right one depends on your size and risk tolerance:

• Phased rollout - go live module by module, or location by location, over time. Lower risk: problems are contained and lessons carry forward. Slower, and it means running old and new systems in parallel for a while. Usually the right choice for larger or multi-entity businesses.
• Big-bang - everything goes live at once. Faster and cleaner once done, with no prolonged parallel running, but higher risk because everything is new simultaneously. More viable for smaller, simpler deployments.

There's no universally right answer; the more complex and critical your operation, the more a phased approach reduces risk.

A go-live readiness checklist

Don't go live on a hope. Confirm, explicitly, that:

• Data is migrated and reconciled - final balances, open transactions, and masters check out against the source.
• User acceptance testing is signed off - the people who'll use it have tested real scenarios and confirmed it works for them.
• Users are trained - and trained recently, on real tasks.
• Integrations are tested - connections to other systems work end to end, not just in theory.
• Permissions and roles are correct - people can do what they need, and can't do what they shouldn't.
• Backups are confirmed working - you can recover if something goes wrong (on Frappe Cloud this is managed; verify it's in place).
• A support plan for week one is ready - everyone knows who to ask when something doesn't work.
• A rollback or contingency plan exists - what you'll do if a serious problem surfaces.

If any of these isn't true, the honest move is usually to delay rather than push through. A slipped date is recoverable; a botched go-live erodes the trust the system needs to succeed.

Hypercare: the critical first weeks

The period immediately after go-live - often called "hypercare" - is when issues surface and users are least confident. Plan for it deliberately:

• Heightened support on standby - your partner and internal champions available to resolve issues fast, before frustration sets in.
• A clear channel for problems - people need an obvious, easy way to report what's not working and get help.
• Rapid triage - fix the urgent things immediately; queue the rest visibly so people know they've been heard.
• Expect the productivity dip - it's normal as people adjust (see Change management). Reassure, support, and it passes.

Hypercare typically runs a few weeks, tapering as issues drop and confidence rises.

Settling into steady state

Once the system is stable, the relationship shifts to ongoing operation:

• Platform and software health is handled by Frappe Cloud - upgrades, backups, monitoring, and bug support (see who does what).
• Functional support for your specific deployment comes from your partner.
• Continuous improvement - most businesses keep refining: adding modules, improving workflows, building on what they've learned. The system should evolve with you, not freeze at go-live.

A closing thought worth holding onto from the start: a business system is not a project that ends, but a capability you operate. The implementation gets you live; the value comes from using it well over the years that follow.

For smaller businesses

A small, standard deployment may "go live" almost casually - you've been testing with real data, and one day it's simply your system of record. The checklist above still applies in spirit (reconcile your data, make sure people know how to use it, confirm backups), just lighter. The free onboarding and Frappe Cloud's managed platform remove much of the operational risk that larger self-managed go-lives carry.