Pilot before go-live: the month-one playbook for new systems

The most dangerous day in any software project is the day you switch off the old way of working. A pilot exists so that day never arrives as a leap of faith. Here is how a disciplined first month runs, and what a pilot has to prove before a system earns the right to go live.

Why the big-bang launch keeps failing

The classic failure pattern goes like this: a firm buys or builds a system, trains everyone on a Friday, and switches over on the Monday. By Wednesday something unexpected has broken, the team has quietly gone back to WhatsApp and spreadsheets, and the system is dead within a month, not because the software was wrong but because the rollout was. Once a team has rescued itself from a failed launch, getting a second chance is twice as hard.

A pilot removes the cliff edge. The new system runs on a slice of real work while the old way keeps running underneath it. Mistakes cost minutes instead of jobs. And crucially, the decision to go live becomes a judgement made on evidence rather than a hope expressed in a meeting.

Anatomy of week four: test, pilot, train

In the AGMM installation timeline, the first three weeks belong to onboarding, build and integration. Week four is where the system meets reality, in three overlapping activities:

• Testing. The installer runs the system against real historical data: last month's enquiries, last quarter's quotes. Integrations built in week three, covered in the integration checklist, get exercised until the edge cases surface.
• Pilot. A limited slice of live work flows through the new system while the old process keeps running in parallel. One estimator, one job type, or one week's enquiries, whatever slice is big enough to be real and small enough to be safe.
• Training. The team learns on the pilot's live examples, not on demo data. Training that uses your own jobs sticks; training on fictional ones evaporates by Friday.

Parallel running: the boring technique that works

Parallel running means doing the work twice for a short period: once the old way, once through the new system, then comparing outputs. It feels wasteful, and that is exactly why firms skip it and exactly why they should not. Two weeks of duplicated effort on a slice of work is the cheapest insurance available against a system that silently produces wrong numbers.

For an estimating system the comparison is direct: price the same job both ways and examine every line that differs. Differences are not automatically defects, sometimes the new system catches what the old way missed, but every difference must be explained before go-live. Unexplained differences are how margin quietly leaks.

The loop matters more than any single pass through it. A pilot that finds nothing wrong was probably too small to be a real test; a pilot that finds problems and fixes them is doing exactly its job. Each fix goes into configuration and training rather than into a private workaround, so the improvement is permanent and shared rather than living in one person's head.

What a pilot must prove

A pilot is a test with pass criteria, not a vibe check. Before it starts, write down what it must demonstrate:

That last row deserves emphasis. Every system fails sometimes. The difference between a good install and a liability is whether failure announces itself or hides. A pilot is your one cheap opportunity to find out which kind you have.

From pilot to go-live, and what comes after

When the pilot passes, go-live in month two is an expansion of something already working rather than a launch of something untried. The old process gets retired deliberately, one workflow at a time, and only when its replacement has earned it. Then the rhythm continues: a month three optimisation review to tune what the first weeks of full use revealed, and a month four expansion into the next process on the list. Teams that experienced a calm pilot adopt willingly, which matters more than any feature, as we argue in getting a trade team to actually use new software.

This staged approach is baked into how AGMM installs systems, and the full sequence from discovery call to expansion is set out on the Commercial page. The playbook is not glamorous. That is rather the point: go-lives should be boring, because everything risky already happened safely in the pilot.