ERP Implementation Strategies – A Guide to ERP Implementation Methodology


Director of Marketing,

In choosing new enterprise resource planning systems, implementation is every bit as important as finding the right program. You should be thinking about it proactively when evaluating systems, you should raise the topic with propsective vendors and even ask for examples of their customers’ strategies. There are hundreds of articles on “best practices” for implementing ERP software, but understanding each strategy and choosing the best option is difficult. So, we set out to consolidate the information in a single guide. Our aim is to give you enough information – and the most important pieces – to choose the best implementation process for your organization. We’ll cover the three most widely discussed ERP implementation strategies:

  • Big bang - Implementation happens in a single instance. All users move to the new system on a given date.
  • Phased rollout - Changeover occurs in phases over an extended period of time. Users move onto new system in a series of steps.
  • Parallel adoption - Both the legacy and new ERP system run at the same time. Users learn the new system while working on the old.

Survey Results – Updated April 1st
We recently hosted a survey to find out which ERP implementation strategies are the most popular and most successful. With the help of Twitter and our favorite industry bloggers, we received 45 responses from organizations that have been involved in an implementation. Our survey was brief and informal with just four simple questions:

  • Which implementation strategy did your organization choose? Big bang, phased rollout, parallel adoption, combo of big bang and phased rollout, or other.
  • If you selected other, please describe the strategy you chose.
  • Was the implementation a success?
  • If you selected no, please explain why.

When it comes to ERP implementations, these questions skim the surface. We understand a myriad of questions and answers would be required to learn when it’s appropriate to choose a certain strategy. Additionally, we realize reporting the “most successful strategy” would be erroneous. While one strategy may work for a majority of companies, it may not be the best strategy for your organization. As Jonathan Gross from Pemeco pointed out, “The circumstances dictate the appropriateness of the implementation strategy. In some cases, a phased deployment might be more appropriate than a parallel deployment. In other cases, it might be the opposite.”

Nevertheless, our survey did uncover some interesting data. Here are the results:

Eighty-nine percent of respondents followed “big bang,” “phased rollout” or a combination of the two strategies.

The number of phased rollout users compared to big bang was split nearly evenly; parallel adoption trailed far behind with only four users; “other” came in last. The “other” respondent left us the following explanation for his strategy:

“Component implementation; pilot projects; alpha testing; refinements and iteration before opening it to entire unit. If successful in a unit, expand it universally until all units have adopted.

Eighty-eight percent of implementations – or 40 out of 45 – were successful.


Of those that answered “No,” we received the following comments:

Logistics problem (visa issue delay, user delay for data collection, delay in top management support). – Phased Rollout

We are still under the progress of phased manner, only “Materials and Finance” is under parallel run and they’re facing some bugs/modifications.  - Parallel Adoption

Still running both systems in parallel, 3 years later!” – Parallel Adoption

1 year late, although all other success parameters achieved.  - Big Bang

Concentrating on tools not architecture.  - Big Bang

Big Bang
Just as the name implies, a big bang ERP implementation happens in a single, major event. All modules are installed across the entire organization all at once, more or less. Of course the changeover from the legacy system doesn’t happen without proper planning. There are many pre-implementation activities that need to be carried out prior to the big bang.

After the planning activities have been successfully executed, the old system will be turned off, and the new system will be launched. At this point there is no turning back. However, there should be fall-back scenarios prepared just in case the initial changeover is a failure.

The big bang implementation strategy has supporters on both sides of the fence. The most common criticism is the risk factor; there are a number of things that could go wrong in an instant changeover. However, the implementation is quick and less costly than a long, drawn-out phased approach. Here is a list of other benefits and drawbacks of big bang implementation:

Implementation time is shorterDifficulties are more pronounced
Implementation difficulties and "pains" are condensedDetails may be overlooked in the rush to change
Costs are much lower than a long, drawn-out implemenationEmployees have less time to learn the new system
Employees only need to be trained on the new system, not for the changeover periodFull end-to-end system testing is tough to carry our prior to implementation
Implementation happens on a single date and everyone knows the dateFall-back scenarios are more difficult than originally perceived
A failure in one part of the system could affect others
There is a catch-up period (see Illustration below)

Another downside of big bang implementations is Ken Eason’s “Initial Dip Phenomenon.” Eason, author of “Information Technology and Organisational Change” and one of the original authorities on implementation strategies, describes an “initial dip phenomenon” which happens shortly after an implementation. This catch-up period happens because users are struggling with the new system and organizational performance temporarily declines as a result.

Phased Rollout
In keeping with the theme of cosmological evolution, phased rollout would be analogous to the Steady State theory: instead of an implementation happening in a single instance, small changes occur over time. An organization moves off the legacy system and onto the new ERP system in a series of predetermined steps. This can be achieved in several different ways. Here are three well-known techniques:

  • Phased rollout by module - This is the most common phased rollout strategy. ERP modules are implemented one at a time. Typically you begin with core business functions – those necessary for daily operations – then add in more modules and functionality with each phase. However, some experts suggest starting with easy modules like general ledger, or beginning with the less mission-critical modules. For a good explanation, read Insight Consulting Partner’s write-up.
  • Phased rollout by business unit - Under this approach implementation is carried out in one or more business units or departments at a time. For example, you begin with implementing the new ERP system in human resources, then move to accounting. Some organizations may put together an implementation project team that travels between each department during implementation phases. As the team gains more experience with each implementation, subsequent phases become more efficient.
  • Phased rollout by geography - For organizations with multiple locations, a phased rollout by geography is a frequent approach. The new ERP system is introduced at one or more company locations at a time. This is also referred to as the “pilot adoption method.” It’s common for large organizations that have multiple locations or independent departments.

Of course there are hundreds of options, including many variations and combinations of these three. Just like big bang, a phased rollout strategy has advantages and disadvantages. This table includes several common viewpoints:

Companies gain knowledge and experience during the initial implementation phase that can be applied to subsequent phasesNot as focused and urgent as big bang
Possible to introduce modules while programming future modulesInvolves continuous change over an extended period of time
With conversion occurring in parts, time is available for adjustmentsEach modules relies on information from other modules, so there could be critical information missing
There is no catch-up period, employees learn as they goSeveral adjustments are needed
More time for users to adapt to the new systemDuration of the project is much longer than big bang
Technical staff can focus on one part of the system or a select group of users at one timeA fall-back to the old system becomes more difficult with each phase
Project members may develop unique implementation skills that they can be positioned for in later rolloutsTemporary bridges must be created between legacy system and new system

Parallel Adoption
The third generic – though less talked about – ERP implementation plan is the “parallel adoption” approach. This has also been referred to as “parallel conversion,” “parallel running,” or “parallel cutover.”

Parallel adoption is thought to be the least risky implementation process. It includes running both the old and new ERP system at the same time. This way users can learn the new system while performing regular work activities on the old system. After requirements for the new system are met, then the legacy system is decommissioned.

Parallel adoption can be considered the middle road between big bang and phased adoption. For example, the pace of the changeover is slower than big bang, but faster than phased adoption. Similarly, user adaptation is easier than big bang, but more difficult than phased adoption.

The major trade-off is cost. Parallel adoption is the most expensive implementation method. Additionally, having employees enter data in both systems is not efficient. However, if the extra costs are less than costs incurred after a backfired big bang adoption, then it’s a reasonable plan. Still, organizations cannot predict cost overruns of big bang, so parallel adoption has become decreasingly popular because of perceived high costs.

Which ERP Implementation Strategy is Best for Your Business?
There certainly is no one-size-fits-all when it comes to implementing an ERP system. Every company has unique goals, and an implementation requires careful planning and analysis. Some companies may choose a combination of strategies, like a mini big bang mixed with phased rollouts (i.e. “big bang” the important modules, then add in the peripheral modules later). Others may choose to implement a mid-market ERP system (e.g. Microsoft Dynamics, Epicor) at the plant-level, while keeping a major ERP system (e.g. SAP, Oracle running at headquarters). And at times, the best implementation strategy will be obvious.

At a minimum, we hope this guide gets your organization off on the right foot. By choosing one of the above or developing an entirely custom strategy, you should be well on your way to success.

  • Leslie Vail

    Hi Houston,

    Neat article. It has been my experience that whenever a ‘parallel’ implementation was attempted, they end up with both systems being wrong. It’s hard to remember to do everything in each system.

    I used to work for a bank and whenever we did a software change it was big bang over a long weekend. We used to call it ‘Bet the Bank Weekend’.

    I worked for a CPA firm before the bank and the CPA firm had an implementation strategy that they called ‘method 1′. It translated into ‘do it right the first time’ (LOL) another ‘big bang’ method.

    I’ll be interested in how your poll comes out.

    Kind regards,


  • Mark Polino

    The other hidden cost in parallel adoptions is garbage in the old system. Even when doing parallel testing, the issue with differences is typically that the system being replaced didn’t actually work in the way users thought it did. It takes a lot of time to track that down and prove that conclusion.


  • Frank Hamelly

    I agree with Leslie and Mark’s comments. Big Bang is the best way to go. It focuses the teams’ efforts and commitment because once the switch is flipped, there’s no going back. Phased rollout can work but because Go Live is not focused on a single point in time, the total cost and effort expended is greater.

  • Richard Daigle ERP PM

    Dear ERP Forum,

    It has been my experience that whenever a client insist on going parallel, a) they either have psychological issues letting go of the old system, or, B) they simple are risk averse, both of which are not addressed by going parallel.

    One of my earlier engagements involved a Controller who insisted on going parallel; the AP conversion was first at bat, so I reluctantly agreed to go along with it. The AP person was skilled and did a great job entering the data in GP version 4 and she was about to do the same in the old system when I noticed the feathers starting to fly at the AP desk. Apparently, it was then and only then she realized she was mentally unable to process that same data in the old app. Why? Here’s why. She had just organized all that work and placed it aside and would have to disturb all that in order to get this same info in the old system. We have a rule on my engagements, if it’s not fun we don’t do it, so that was the end of that!

    People are not machines. Bad enough we are asking good people to do something in a new way. Keep it positive. Stay in the happy place. “Simplify things, give shape to fundamentals, and make sure it all works!”


    Rich Daigle, MBA, MBSC, PMP
    ERP Program Manager
    603-860-4575 C

  • Todd

    Great summary.
    I agree with the other posts, a parallel project may seem like it has the least risk, but in today’s complex world you can’t compare the new system to the old. You end up chasing issues that are not problems.

    The new system is an orange, the old is an apple. You just can’t compare them.

    While a phased approach might seem easier than a big bang, I have found that a little anxiety gets people motivated to actually work on the project. It’s that motivation and team-player attitude that will make a project work; even if you pick a more difficult method.

  • Eric Boes

    We generally recommend running parallel in a test mode, taking one department at a time for a day or two and ensuring that the results correlate, especially if there has been extensive development. We have found that doing that uncovers unspoken “requirements”, validates training, and ensures that users are engaged prior to going live for real.

    Once parallel testing is completed, we recommend a phased approach. We would almost never encourage a big bang approach unless the implementation was very small. It is best to build experience one department at a time if possible and users who have been on the system for a month or so can help with problems that arise and serve as mentors to departments just coming on line.

  • Gerald Poe

    Here is our theories, preacices, and approaches:
    1) Big Bang was more effective because straglers are avoided and holistic cleanliness is possible.
    2) Phased-rollout is good, but slower and more error prone and reauired much more macro/micro management processes.
    3) Parallel adoption is truly the best, if possible, as it allows overlap and fall-back controls. However it is the most resource intensive and in today’s LEAN operations head cont and other IT and technical resurces are scarcer than a hen’s teeth. Costly and resource depletion.



  • Ibrahim

    With regard to Phased-rollout vs Big Bang, it does of course matter on the individual project, but as a rule of thumb, you acutally implement an ERP system in order to benefit from the integration aspect. The more modular roll out phases, the less integration benefits you will receive. On the projects I have worked we have only gone for phased rollouts based on geographical locations.
    I agree with most of the comments on parallel run, if at all one should counter all risks by extensive testing and if required by a parallel run prior to actual go live.

  • Mauricio Torres

    Very good article. I have implemented different ERP software system in several countries in South America. I prefer to choose big bang when there isn’t an ERP system already installed, or when it’s not critical to have information (live) in both systems and historical information of the old year. However, in some cases I prefer phased rollout.

  • Rodrigo Castro

    Neither one of these approaches guaranties Business Results (return from investment). They only guarantee Go Live, which is not a Business Result (BR). And this is no rocket science, it is simple: What you don’t measure doesn’t exist. So the first thing to do is to formalize wanted BRs and control them as part of the project. Second, and most complicated for ERP software implementators is to turn the whole thing around: you cannot govern the project with the ERP modules like you guys do now…that is the biggest reengineering of the methodology. You have to establish a set of leading indicators of the final desired BR. Also you have to work on “timeboxes”: fix time (i.e. 3 or 4 months) and obtain 80% of the result with 20% of the effort and then reformulate as if you were starting the first Timebox again but in a shorter time span. This will change your life and turn you into Business People instead of Technology Consultants. My email:

  • Jigs

    I agree and respect all the comments hereby. However I am sure all 3 implementation strategies are good in their own way. So can I know what parameters are to be considered beforehand going for any of these 3 strategies

  • Binish

    Hi Houston, I am in the implementation field for almost 8 years now and found that, if more customization is required and end-user acceptance is low (due to lack of knowledge/inertia) parallel alone works… all other cases jump into the big/mini bang for best results -your graph shows the clear picture. good job

  • Bharathi NM

    Addressed well!!

    We are currently on implementation, chosen parallal to have a safe play. Once the basic platform created and then should move to customization, the important thing is the engineer should have a presentation skill as well listening attitude to lead for success. Every suggestion to be reviewed.

  • vic

    Thank you, very informative article. I am writing a paper about ERP implemetation as my final assigment. This article was very helpful.

  • Farid Bahgat

    It’s grateful to have different opinions, I do agreed that there is no perfect selection suit for each company, in my opinion parallel for a short period is best and safest selection.

  • ERP training

    I agree with Todd – it’s a bit comparing apples and oranges.

    We’re on the user training side of implementation projects since 1997.

    We’ve seen big bang projects go extremely well, and also big bang disasters.

    External consultants not fully knowing the business processes, process owners not realizing the impact of their choices for international roll-outs, the amount of customizing, user adoptance, etc.

    It’s hard to evaluate these ‘people’ effects but they can distort ‘success evaluations’ of an ERP implementation project approach.

  • Brett Beaubouef

    Great article on deployment strategies. I would like to suggest that there is not a single ERP methodology that covers all the disciplines required for an ERP implementation. The trick is to learn how integrate these different methodologies together. For additional information please see the following article:

  • Richard Chege

    Great article. I’m busy with the deployment of an Integrated Public Debt Management System which integrates SWIFT payment instructions to banks. I’d like to enquire from the bloggers whether anyone has done SWIFT integration before and which is the best option to switch over; parallel running with the old system (non-swift) or Big bang. My email:

    • Dynamicpm

      Mr. Chege.  I am familiar with Tibco and other data integration engines that have specific SWIFT mapping data type trees.  These projects are almost always rolled out in a phased manner with the legacy system kept in tact for a back up.  The ciriticality of the data and underlying financial risks are too great for a big bang approach.

  • Chris Shaul

    Rereading this article again after a while away from it.  It made me think about clients who wanted or tried to go live after running parallel.  It was chaos and hell for the employees.  The systems processed things differently and the financial numbers where different.  Not way out of balance, but enough to cause a lot of heartache.  They had a hard time realizing that they were capturing different information in a different manner.  Further, a single transaction in a deeply integrated system can roll up differently depending upon the settings.  Also parallel processing has a high chance for error in employees missing an entry in one of the two systems.  Simply a headache.  

    I’ve seen that phased or “mini-bang” solutions are often chosen, although there is something to say for Big Bank approach if everything was well planned and the users were well trained.

    Thanks again for this article.


  • Blogs by Market:
  • Subscribe to the Software Advice Manufacturing Blog

Popular Blog Posts