Phased go-live

A phased go-live splits an implementation into slices that go live independently. The slice may be a module, such as inventory before finance; a location, such as one plant or campus before the rest; or a user group, such as one sales region. Each phase has its own data migration, training, cutover and hypercare period, and the lessons feed into the next.

Sequencing is the design decision. Start with the module that has the clearest boundary and the most visible pain, prove the migration and support process, then move to modules with heavier dependencies. Timing matters too: institutions plan around the academic calendar, retailers avoid peak season, and finance modules avoid quarter-end.

It is not the same as a big-bang go-live done slowly. Each phase must leave the business in a working state with both old and new systems clearly assigned ownership of data. Running two systems indefinitely because nobody scheduled the last phase is the common failure.

• Operations head: only one part of the business changes at a time, so support load and disruption stay manageable.
• CFO: spend is released phase by phase, and each phase must show adoption before the next is funded.
• HR head: training is targeted at the group going live, rather than the whole company at once.
• CTO / Head of Engineering: integration and migration problems surface on a small slice where they are cheap to fix.

Big-bang implementations put every process, every user and every integration at risk on the same day, with the whole support team overwhelmed at once. Phased go-live exists to shrink that risk to one slice at a time, so that problems are contained and fixes are applied before the next phase. The trade-off is a longer overall programme and a period of running old and new systems together, which needs interim integrations and clear data ownership. It also needs discipline to finish: each phase should have a date, and the final one should retire the old system.

• A university ERP going live with admissions and fees before academic records, timed to the intake cycle.
• A manufacturer's ERP rolling out inventory at one plant, then production, then finance, then the second plant.
• A hospital network activating a new HIS one facility at a time with a shared support team.
• A retailer's new POS and inventory platform rolling out region by region, well before the festive season.
• A logistics company migrating dispatch city by city while the legacy TMS still handles the rest.

Technique / practiceAn implementation practice, not software. It is how Eazyware delivers Enterprise Platform Implementation and ERP programmes: fixed-price phases, each with migration, training, cutover and hypercare, sequenced around the client's operating calendar.

Eazyware service that covers it: Enterprise Platform Implementation. Starting prices are on the pricing page.