Draft for Tamir's review. Not published.
Test readiness on your own work
Run real transactions through the system end to end, by the people who will use it. Think of orders from receipt to shipment, a payroll with its exceptions, or a ward's downtime drill. Check migrated records for a sample against the old system, with the people who know them.
When the migration surfaces rules nobody can confirm, treat each one as a decision for a named owner, because the system will apply it every time. Go live only with rules someone has signed, especially those touching safety, labor agreements or pay.
Decide on criteria, with a way back
Hold a go or no-go meeting with written criteria and a named decision maker. Know the cost of a failed cutover and the cost of a delay, so the stakes are clear. Read the contract for what a postponement costs and who decides it.
A staged go-live by site, depot or line often keeps the date for what is ready. Test the rollback in a realistic scenario and time it. If you are already live and results fall, decide in days on data: where the time goes now, and whether the fixes land in time.
Depending on your seat
If you're on the board, the decision belongs to management, and you should know it rests on evidence. Ask for the criteria, the tested fallback and the support plan, and for the decision's record afterward. If an authority asks the chair about readiness, get the status in its own measures first.
If you run IT or own the product, separate the vendor's milestone from your own readiness. A public service usually carries accessibility and language obligations whether or not the contract repeats them. For a product launch, set the quality bar from the failures customers tolerate, and launch first to a segment that clears it.
What to check before you decide
- Run real transactions end to end with the people who will use the system, and record what fails.
- Check migrated records for a sample against the old system, with the people who know them.
- Keep a register of business rules with source, owner and status, and load only signed rules.
- Test the rollback or fallback in a realistic scenario and time it.
- Confirm named support on every shift for the first weeks, with escalation to the vendor.
- Hold a go or no-go meeting with written criteria and a named decision maker.
- Check the contract for what a postponement costs and who decides it.
Questions people ask
ERP go live is weeks away and management says ready, should the board be involved in the decision?
The board should not make the decision but should know it is being made on evidence: a go or no-go with written criteria, a tested fallback and support on the floor. Ask for those three things and for the decision's record. It depends on how much the go-live can disrupt production and on whether the criteria exist.
The authority is asking our chair about ticketing rollout readiness and management's reports are brief, what should the board know?
The board needs the rollout's state in the authority's terms: vehicles and stations done, tests passed, open issues and dates, and the risks to the deadline. Ask management for that format and for an independent check before the chair answers. It depends on what the authority measures and on how far the rollout is.
Control system cutover happens in the next turnaround, what should the board ask before the window?
Ask for the readiness evidence: factory tests passed, the cutover plan staged with fallback, the vendor's team confirmed on site, and the decision criteria for proceeding or deferring parts. Ask for the cost of a failed cutover and of deferral so the decision makers know the stakes. It depends on the scope in the window and on whether partial deferral is possible.
Warehouse system went live before peak, picking doubled and orders ship late, roll back or push through?
Decide in days rather than weeks, on data: where the time goes now per order compared with before, and whether the causes are fixable in a week. Usually a few configuration and data problems cause most of the loss. Roll back only if the fixes cannot land before the peak and the old system can still be run safely. It depends on what rollback costs in data and on whether the vendor's fixes are already identified.
Our AI product has been in beta for months and the team won't launch until quality is better, how do I decide when to ship?
Define the quality bar from customers rather than from the team: which failures customers tolerate and which lose them. Launch to a segment where the current quality clears that bar, and keep tuning for the rest. It depends on the failure types the product still has and on which customers can live with them.
Should we open the new warehouse before its systems can complete orders?
Separate occupancy from customer fulfilment readiness. The decision depends on demonstrated order completion, fallback capacity, and a clear business owner for accepting any residual limitation.
Should we delay payroll system launch when readiness evidence is incomplete?
Decide against complete payroll outcomes and a workable fallback rather than the schedule alone. It depends on reconciled calculations, known exceptions, employee impact, and approval by finance and payroll owners.
Clinical system go live in six weeks, vendor says ready, nursing says not, how do I decide whether to go?
Go-live readiness is a set of tests the hospital runs, with the vendor as one input. Run the critical checks yourself: data migration on real records, downtime procedures on each ward, support cover on the first nights and a rollback that works. It depends on which of those checks fail and on whether a short delay fixes them.
Scheduling system migration keeps finding rules nobody can confirm, how do we handle it without losing the date?
Treat every unconfirmed rule as a decision for a named owner, because the system will apply it on every roster. Keep a register of rules with source, owner and status, and go live only with rules someone has signed. It depends on how many rules touch safety and labor agreements, and on whether a staged go-live by depot or line is possible.
Government service failed accessibility testing and the Arabic version is incomplete, vendor says out of scope, launch or hold?
Check what the contract and the published requirements actually say, because public bodies usually carry accessibility and language obligations whether or not the contract repeats them. Fix the blocking accessibility failures before launch and set a short dated plan for the rest. It depends on which failures block use for people with disabilities and on your legal obligations for language coverage.
Should patient identification risks delay our hospital system migration?
Specify false merges and missed matches separately. Acceptance depends on identifier quality, ambiguous records, and a safe process for review and reversal.
How I can help with this decision
- Ask or talk (Free)
- I give my view on which readiness checks decide a go-live like yours, and how to run a go or no-go both sides accept.
- Review (Pay if it was worth it)
- I write an independent readiness assessment against your migration, testing, fallback and support evidence. I recommend to go, delay, stage or change scope, with the conditions for each.
- Retain (When it makes sense)
- I stay close through go-live and stabilization to review the daily issue list and the vendor's fixes.