We fit every system MODULE into its wall bay

How we read a business before we touch a system

A rollout begins with a reading week. We sit with the people who actually push the paperwork — the buyer who still keeps a whiteboard of promised dates, the warehouse lead who knows which three bins are always wrong, the controller who rebuilds the monthly close by hand. From those conversations we build a map of how information truly moves, which is usually quite different from how the current software was configured.

That map becomes the first set of module tickets. No ticket is opened without a named owner and a named reviewer inside the client business. Where a department cannot yet name a reviewer, we do not configure that area. This single rule prevents more failed rollouts than any technical decision we make.

Written notes beat clever promises

Our work is deliberately papered. Migration sheets list every source file, row count, transformation and exception. Go-live notes record every action on cutover night in the order it happened. Data audit rounds produce a variance memorandum that the controller signs. When an audit arrives two years later, client teams can reconstruct the entire rollout from those documents alone.

This is not bureaucracy for its own sake. It is how we keep a promise that a rollout will be reversible. A change nobody wrote down cannot be undone safely.

What kinds of business we serve

• Light manufacturing and fabrication shops moving from paper travellers to a connected production and inventory platform.
• Wholesale distributors who need purchasing, receiving, pricing and order entry to share one item master.
• Field service contractors replacing disconnected scheduling spreadsheets with work order and billing flow.
• Food, agricultural and cold-chain operators who must trace lots and reconcile yields against scale tickets.
• Professional service firms consolidating time, billing and project accounting onto one finance module.

The four questions we ask at every rollout sitting

One. What breaks first if the books are wrong on Monday morning? The answer tells us which module must be configured with the most care and rehearsed the earliest. Two. Which three reports does leadership trust today? Those reports are rebuilt and reconciled before anything else goes live. Three. Who can approve a rollback at two in the morning? We insist on a name and a phone number, not a committee. Four. What does a good first week look like? We write it down, we post it at the go-live desk, and we measure against it.

Weeks one to two: reading and ticketing

We run the reading week, map the flows, and open the first module tickets. By the end of week two the client has a written scope, a list of open questions and a named owner for every area. Nothing has been configured yet, and that is intentional.

Weeks three to six: configuration and first migration sheet

Module ticket bays are worked in sequence, starting with shared masters — chart of accounts, item master, customer and vendor records, tax rules. The first migration sheet run brings in those masters only, so every later run has a stable foundation. Rehearsal begins in the sandbox as soon as a department sees its screens working.

Weeks seven to ten: rehearsals, audits and corrections

Two sandbox windows of two days each are held with real users entering real transactions from a recent week. Between windows we run data audit review rounds against source ledgers and correct the mapping exceptions. This is usually where the most valuable conversations happen, because users finally name the edge cases in their own work.

Week eleven: the go-live note desk

Cutover is scheduled on a Thursday evening where possible. The go-live note desk opens with the client controller, the operations lead and our rollout lead present. We run final migrations, verify opening balances, release the first screens and watch the first morning of live transactions from the desk. The note board stays up through the following Monday close, and every entry is reviewed and closed.

Weeks twelve onward: stabilisation and handover

The first two live weeks are stabilisation. We hold daily fifteen minute desk reviews, correct any routing or permission issues, and produce the final handover pack: completed tickets, signed migration sheets, the go-live note record and the audit memorandum. After handover we remain available through the support address listed below.