Phased or Big Bang ERP Implementation: Choosing a Safe Go Live Strategy

A manufacturing company scheduled the launch of its new ERP for a Monday. The weekend before, the entire old system was switched off and the data moved. On Monday morning the cashier could not issue invoices, the warehouse could not print delivery notes, and the stock report showed nonsensical numbers. For two weeks the team worked with emergency spreadsheets while customers waited. A project designed over eight months was nearly halted by one decision: everything moved at once.

The go live strategy is one of the most important decisions in an ERP implementation, yet it is often taken too lightly, sometimes merely out of a wish to finish the project as fast as possible. The two main approaches are big bang, where all modules and business units move on a single date, and phased, where the move is made per module, per branch, or per function in several waves.

This article compares the two approaches, explains the factors that determine the right choice, details the preparation that must not be skipped such as data migration, testing, and training, and offers a readiness checklist, a fallback plan, and ways to stabilise the system after launch. The aim is for your go live decision to be taken with open eyes.

Summary

• Big bang is fast and avoids dual systems, but its risk is concentrated on a single day
• A phased launch splits risk and leaves room to learn, but demands temporary integration
• The best choice depends on complexity, risk tolerance, organisation size, and data readiness
• Data migration, acceptance testing, and training decide success more than the strategy itself
• Prepare go/no-go criteria, a way back to the old system, and intensive support after launch

The two main approaches

In a big bang, the entire organisation stops using the old system and starts using the new ERP on the same date for all modules covered: finance, sales, purchasing, inventory, and more. There is no overlap period, so there is no need to keep two systems running in parallel for long.

In a phased approach, the move is divided into waves. There are several variations: by module, for example finance first and then inventory and sales; by location, for example one pilot branch and then the others; or by business function. Each wave yields lessons used to improve the next.

There is also a parallel approach, where the old and new systems run together for a set period and the results are compared. This gives a sense of safety but doubles the workload because every transaction is entered twice. Parallel running is normally used briefly and in critical areas such as period closing.

Pros and cons of big bang

The main strength of a big bang is simplicity of concept and outcome. The whole organisation works with the same data and processes from day one, no temporary interfaces between old and new systems are needed, and the full benefit is felt sooner. Total project cost is sometimes lower because the transition is shorter.

Its weakness is that all the risk is concentrated in one moment. If there is a fundamental problem with data or configuration, the impact is felt across the whole company at once. The training load also piles up: all employees must be ready on the same day, and the support team is swamped by questions from everywhere.

Big bang suits relatively small and simple organisations with uniform processes, few modules, and clean data. It also makes sense when the old system can no longer be sustained, for example when support ends or it no longer complies with regulations, leaving no choice but to move fast.

Pros and cons of a phased launch

The strength of phasing is shared risk. Problems that appear in the first wave affect only part of the organisation, and the team can fix them before the next wave. The project and support teams can concentrate their attention, and users are trained in turn so the learning sticks better.

The downside is a longer transition and old and new systems living side by side. You need temporary integration so data flows between them, for instance stock from the new module that sales in the old system must be able to read. This temporary integration wastes money and is a source of its own errors.

Another risk is project fatigue and lost momentum. If waves run too slowly, enthusiasm drops and doubt grows. Set a clear wave schedule and avoid letting the dual systems drag on indefinitely, because "temporary" tends to become permanent.

Factors that decide the choice

Complexity is the first factor. The more modules, legal entities, locations, and integrations, the greater the risk of a big bang. Organisations with many branches and differing processes are generally better suited to waves, starting from a representative pilot branch.

Risk tolerance and operational dependence are the second factor. If stopping for a few days means losing customers or contract penalties, the risk of a big bang is hard to accept. Consider seasonality too: avoid launching at peak sales or fiscal year end unless forced.

Data and organisational readiness are the third factor. A big bang demands clean data and employees ready at the same time. If data quality is still in question or resistance to change is high, a phased approach gives time to fix things and build support through positive experiences from early waves.

Project team capacity is the fourth factor. Phased waves need a team that can last longer and handle several launches, while a big bang needs a very intense peak effort in a short time. Choose what fits your real resources, not what is ideal on paper.

A sensible module order for a phased approach

Many companies begin with the foundation: finance and the general ledger along with master data, because other modules depend on it. After that come purchasing and inventory, then sales and billing, then specialised modules such as production, projects, or HR. This order follows data dependencies so temporary integration can be minimised.

An alternative is to start with areas of high business value and low risk to win early victories that convince the organisation. For example, a reporting or purchase approval module that frees up much time, before touching core processes such as the more complicated production.

Whatever the order, set firm boundaries for each wave, measurable success criteria, and a lessons review before the next wave begins. A wave without exit criteria simply becomes a project without an end.

Preparation that must not be skipped

Data migration is the most common cause of go live failure. Clean master data such as customers, suppliers, and items well in advance, run migration tests repeatedly, and reconcile the results against the source: account balances, inventory value, and receivables must match before and after. Do not wait until the last week to discover that the data does not match.

User acceptance testing must be done by the people who actually run the daily processes, using real end to end scenarios: from incoming order to payment, from purchase to goods receipt. Testing by the technical team alone does not catch flow oddities that only users recognise.

Training needs to be role based and held close to launch day so it is not forgotten. Prepare short guides, videos, and a group of superusers in each department who can help their colleagues. Training that is only a general presentation is rarely enough to change working habits.

Communication is often underestimated. Tell employees, customers, and suppliers when the change happens, what changes for them, and where to ask for help. Customers who know invoices may be slightly late in launch week are far more forgiving than those who are surprised.

Go/no-go criteria and a fallback plan

Before the launch date, set objective criteria that must be met: all critical test scenarios pass, migration balances match, key users are trained, support is ready, and a backup of the old system is available. An honest go/no-go meeting saves many projects from a premature launch forced by a deadline.

Prepare a realistic rollback plan. Define the point of no return, when the old system can no longer be used, and make sure that before that point you can step back with data intact. For a phased launch, ensure there is a way back to the old process for a problem wave without damaging other waves.

1. 01Clean and validate master data, then run repeated test migrations
2. 02Run end to end acceptance testing with real users
3. 03Train employees by role and prepare superusers
4. 04Set objective go/no-go criteria and review them together
5. 05Prepare a rollback plan and a clear point of no return
6. 06Form an intensive support team for the first weeks
7. 07Communicate the schedule and impact to employees, customers, and suppliers

After launch: hypercare and stabilisation

The first two to six weeks after launch are the most fragile. Form a hypercare team ready to answer questions and fix problems quickly, with an easy reporting channel and clear priorities. Record every recurring problem as a sign of training or configuration that needs correcting.

Monitor health metrics: number of successful transactions, system errors, processing time, document backlog, and user satisfaction. The first month end close after launch is an important test, so give the finance team special support and compare results with the previous period.

Once stable, shift focus from merely surviving to harvesting benefits: simplify processes, automate manual steps, and use the new reports. Many organisations stop at go live although the greatest value of an ERP comes from the continuous improvement that follows.

Example: a distributor with five branches

A distributor with five branches and about a hundred employees originally planned a big bang. After assessing the risk, they chose waves: first finance and master data at head office, then inventory and sales at one pilot branch, then the other four branches in sequence six weeks apart.

The pilot branch exposed several price and unit of measure configuration problems that would have hit every branch under a big bang. Fixes were made before the next wave, so the last four branches moved very smoothly. The total time was a few months longer, but no operating day was lost.

The lesson: the extra time of a phased approach is often repaid by the problems that did not happen. Schedule discipline is still vital so waves do not drag on.

Closing

There is no universally correct go live strategy. Big bang suits simple organisations with clean data and a strong reason to move fast; a phased launch suits complex, multilocation organisations that cannot stop operating. What decides success is the quality of preparation: data, testing, training, go/no-go criteria, and support after launch.

Involve process owners from the start, discuss risk openly, and do not let a deadline beat readiness. An ERP launched calmly and in stages will deliver benefits sooner than one launched in a rush and then repaired for weeks.