Skip to content
Ross Barnes-Moore24-Jan-2023 16:40:3035 min read

ERP Fundamentals: ERP Project Phases


So ERP’s not a new thing, it’s been around a long time. As with all technology ERP systems have evolved and been refined over the years, they are faster, more automated, more integrated with better analytics and displays, accessible via apps on your phone while you’re on the move. 

There’s more ERP options to choose from and more competition in the marketplace. Back in the day there were a limited number of suppliers offering a limited number of ERP solutions, now there’s a vast array from the traditional big players to small niche independent suppliers offering fast, nimble deployments.

Implementing an ERP system can be a daunting task

where do you even start?

When a company plans to upgrade or move to a new ERP system it will go through some kind of ‘Spec and Select’ exercise.

This enables the business to outline their needs and specifications while evaluating how the various ERP products fit these business needs. 

The end goal of this ‘Spec and Select’ exercise is to select an appropriate ERP package that will deliver their requirements, and also an Implementation Partner with whom they will work to deliver the project.

The fundamental mistake most organisations make is to focus the ‘Spec and Select’ process on the product, they get caught up in understanding all the functionality the product can offer, all the ‘nice to haves’, rather than being focussed on what it can do for them.

They may have a specific product in mind and they focus on how to make this product fit their business rather than the other way round.

We know that an ERP system is essentially a big box of standard business processes. 

The key is to think about your business processes and your strategy to really understand what you want and which solution provides the best fit to your needs.

Clearly specify what you need your ERP system to be able to do

Detail the business processes you need the product to be able to satisfy and deliver.

Clearly defining the functional business requirements will enable the ERP vendor to evaluate whether the specific business processes can be achieved through the standard processes offered by the product or whether there will need to be some level of customisation or development.

Where there is some level or customisation or development needed the vendor should then be able to provide a high-level view of the effort to deliver the solution based on the complexity. As well as the business processes, think about the non functional requirements you need from the product. 

Examples of non functional requirements may be:

How should the solution be delivered? 

On premise i.e. software is installed and housed locally on the organisation’s infrastructure and servers, or via the cloud where the software is installed offsite on the cloud, accessible to the organisation but managed and monitored by someone else. 

How will the solution be accessed?

What devices should the ERP solution be accessible from - desktops, laptops, macbooks, mobile devices, IOS and android? How the system needs to be accessed and viewed can influence the solution that needs to be deployed.

What geographies need to have access to the solution?

Not only will this influence the actual rollout of the solution, time zones that need to be covered, the proposed makeup of the implementation team, it will also influence the support model that needs to be put in place thereafter.

Chances are that Global solutions deployed to numerous worldwide sites will need 24 x 7 support whereas a single UK site may only need support during UK working hours.

Project roles and responsibilities, what do you as the client want to manage versus what you anticipate your implementation partner providing. Clearly defining roles and responsibilities will help to establish the boundaries and ensure the vendor proposals are targeted and accurate. What are you intending to manage in house versus what skills you need from a third party.

For example, you may have an internal training team who can manage the rollout of training within the business, as such the vendor does not need to account for this. 

Select the product that best fits your needs. 

All your requirements should be bundled up into a Request for Proposal document that can be shared with the ERP vendors, against which they can build their proposal.

A part of the select process you should ask that the vendor demonstrate the product and how it meets the requirements you’ve outlined. This is your opportunity to truly understand how the ERP product will meet your requirements.

From this you should be able to determine which ERP product you want to select.

Select an implementation partner for your ERP Project

Once you’ve determined which product to go with, you then need to think about which implementation partner you want to help you on the journey. Who do you want to support and guide you over the coming months? Who will help you to make this implementation a success?

Like when you do work on your house you want to get a few comparative quotes from your Systems Integrators to ensure you get the right partner and the right deal.

Each prospective Implementation Partner will submit a proposal outlining to you as the customer exactly what they are offering based on their understanding of your requirements. 

This will detail the scope of the services they are offering as part of the piece of work, the resources they are proposing to use, how they will structure and execute the project - the methodology they will use, it may detail specific deliverables that will be produced at the end of each project phase.

For example, the supplier may propose to utilise a mixture of onshore and offshore resources to deliver the project, in this scenario you need to be clear on how this will be managed and consider whether this would work for your organisation or not.

The supplier may also detail what they expect of you as a customer and what your responsibilities will be in order to make the project a success. Most importantly they will outline how much they expect the piece of work to cost. They may also include some assumptions on which their proposal is made which you will need to verify.

The challenge for you as a customer is comparing the proposals received. No matter how prescriptive you’ve been in terms of your requirements and needs, it’s unlikely that your suppliers will have provided like-for-like proposals. There will be differences between them, as such you will need to find some way of scoring the suppliers in order to ‘normalise’ and compare their proposals to determine the best fit. You need to ensure you are comparing ‘apples’ with ‘apples’.

When you’ve evaluated the proposals there may well be a clear front runner from the scoring process, or there may be very little to differentiate between the suppliers. If there’s a clear front runner then the decision is easy. If there’s little between the suppliers then the decision is slightly more complicated and comes down to personal preference and following up on references. Speak to the people they’ve worked with previously and get their view on what worked well and what didn’t to see if that can help the decision. You need to be able to substantiate your decision so it’s always good to document your reasons for selection but it’s worth remembering that whoever you choose you're going to be working very closely with them for a number of months.


To make your ERP project a success there are a number of key roles that need to be fulfilled. 

The Project Sponsor may be an individual or small group of individuals who in effect own and sponsor the ERP project. They are generally executives who are influential in running the business and delivering to the business strategy.

As sponsors of the project they have bought into the business case and see the benefits that the project can deliver, they are the main project advocates and visionaries. They will have been instrumental in initiating the project and making it happen. Chances are they will also have been responsible for securing the budget to support the project.

Once the project is up and running, the Project Sponsor continues to play a key role in the project’s success and has a number of key responsibilities in relation to governance, decision making, overseeing delivery, supporting the management of risks and communication. 

The sponsor needs to validate that the project is on track to deliver the expected value to the business. They are accountable for its overall delivery and success. They can add gravitas to the project from a business perspective to ensure it gets the appropriate level of support and input.

A successful ERP implementation relies on the active engagement of numerous stakeholders across the business. People who have a vested interest in ensuring that the project is a success.

A tried and tested method of achieving this is through the effective use of a Steering Committee, which is generally made up of a number of senior managers or executives from across all the functional areas of the business.

This group of individuals provide direction and alignment across the project ensuring that the project achieves the desired benefits and stays on course.

They are responsible for approving changes to project scope.

The ERP Project Manager is responsible for the day to day management of the project. They have overall responsibility for developing the plans and ensuring deliverables are achieved on time and within budget.

They are responsible for monitoring overall progress and for ensuring that risks which may impact the delivery are raised and appropriately mitigated. They direct the delivery team and are responsible for reporting to the Project Sponsor and/or Steering Committee.

Few business processes only impact a single department or division within an organisation. Most business processes spans across multiple departments and areas of responsibility, taking Procure to Pay as an example, Procurement may have responsibility for the raising of a Purchase Order and interaction with the supplier through to the receipt of the goods, however, the Accounts Payable department will be responsible for the payment of the supplier and management of the supplier account. From a functional responsibility perspective this end to end process is likely to fall under at least two different departments - Procurement and Finance.

This is where the Business Process Owner comes in, they are responsible for managing the end-to-end process and understanding how that process fits within the bigger picture. The Business Process Owners have responsibility for understanding how this process fits within the bigger business picture, for ensuring it runs smoothly and for looking for process improvements. The Business Process Owner also has responsibility for ensuring the data required for their specific business process is fit for purpose, accurate and complete.

Depending on the size of the project you may well have a Project Management Office (PMO) in place. A good PMO should enforce the standards of the delivery to ensure that the delivery is truly exceptional rather than just average.

They track delivery of the plan against the milestones ensuring everything is on track. They implement appropriate tools and processes for tracking and ways of working on the project to ensure standardisation across the project. They prepare reports, support communication, manage resource planning and ensure the right level of project governance is in place across the project.

A good PMO supports the project manager and the senior stakeholders and if the role is done well they can be the glue that holds the whole project together. The ERP Solution architect is responsible for providing technical expertise to the project.

These are responsible for ensuring the effective technical governance of the ERP solution and design, ensuring it complies with the enterprise architecture frameworks within the organisation.

The Solution Architect needs to consider the bigger picture to evaluate how the ERP solution sits within the wider systems landscape and how it interfaces with any peripheral non ERP system and also external systems.

They should also provide the technical parameters and best practice within which the project team should function. Defining the ERP landscape in which the project should function i.e. the systems that should be used for testing, training etc.

Super users are in effect Business Subject Matter Experts (SMEs). To ensure the success of our ERP project we need to engage and involve business users  in the project who truly understand the business processes, policies and procedures.

These people should be experts in their particular functional area and role. They are generally regarded as the ‘go to’ person if you need to know anything. These individuals aren’t always the most senior members of the business team, they are the individuals who know the procedures and day to day activities inside out.

These super users not only contribute to defining an appropriate ERP solution but are also instrumental in the rollout of the project to the business in terms of training and guidance.

Like the Business SMEs, the functional SMEs are experts in their relevant functional field, but their focus and expertise will be from a system perspective rather than a business perspective. They are likely to be resources supplied by the Systems Integrator as experts in their field from a system perspective. They will have a solid knowledge of the ERP package and business processes but will need to learn the specific business processes. Their focus is to gather the business requirements to formulate an appropriate solution to satisfy the requirements and deliver value to the business.

Business Analysts work within an organisation to analyse its business, processes or systems. They work with the organisation to improve processes, products and services. Within the ERP environment they may help the business to define their requirements and to capture these requirements, they will then work with the functional SMEs to convert the business requirements into a usable, fit for purpose technical solution.

The end user is the person within the business that actually uses the end product i.e. in our case the ERP system once it has been developed, tested and rolled out. They are the business users who will have to use the new system day to day to perform their specific business tasks.


So the business case has been signed off and you’ve selected your ERP package and Systems Integrator. 

Now it’s time to get started and deliver the goals laid out in the business case.

“A blueprint is a guide for making something — it's a design or pattern that can be followed. Draw up a blueprint and follow the design carefully. The literal meaning of a blueprint is a paper — which is blue — with plans for a building printed on it.”

In our case the blueprint outlines the plan for building our ERP system, it tells us what we as a project are going to build and deliver to the customer.

It’s the main deliverable of the Design Phase and will detail exactly what will be built in the system to achieve the goals outlined in the Business Case supporting the project.

The blueprint should outline the functional aspects of what the ERP system needs to do, however, it should also cover the technical perspectives of the application and how it should work, detailing how the non functional requirements previously outlined can be achieved. 

The Blueprint should help everyone to understand what the end solution will look like, detailing the business processes that are in scope and specific business requirements. 

Along with the business case it’s the document by which the project success will be measured. 

At a more granular level than the business case it enables you to set the business expectations around what the ERP system will deliver for them.

The clearer and more comprehensive your business blueprint the better chance of business buy-in, the better your system build and the better your project’s chances of success.

The blueprint should be the minimum list of things you will deliver as part of the project, not a list of things you might deliver if there’s time and resources available.

Wishy, washy, ambiguous blueprints that don’t clearly outline what the business will get are useless and often only lead to contention and misunderstandings further down the line. The business thinks they are getting one thing when actually you’ve delivered something else as you ran out of time or budget. This only leads to disappointment and perceived failure.

Clearly understanding the scope of the project enables you to confirm that it’s achievable within the allocated budget, and also to confirm that it can be achieved with the budgeted resources and in the prescribed time frame. If not then some rethinking might be required.

A clear blueprint also enables you to manage future changes to scope. Simply put if it’s not in the blueprint then it’s a change to the project scope that needs to be evaluated as it may impact budget, resources and timeframes. 

If the scope of the project is not definitive then managing the additional ‘urgent’ business requests and ‘things that have been forgotten’ becomes almost impossible.

Being able to clearly manage the scope of the project is critical to ensuring delivery.

Your SI will be keen to pin down and agree the exact scope of the project as this will be how their delivery will be measured.

They need to be clear on what has been contracted for and what falls outside of this which they could charge the business extra for.

The business is key to delivering a clear design. Workshops to understand the scope of what they are doing at the moment, what works well, what doesn’t - what are their pain points all need to be understood. Understanding their business processes and inefficiencies helps to define the future ‘to be’ state.

The ERP system is delivered with a standard set of ‘best practice’ business processes and ways of working. 

Deviations away from this standard set of processes generally requires additional customisation or development effort which will have an attached cost. 

The more non standard developments the greater the implementation costs and also the ongoing support costs. 

Rather than changing the system to fit the way the business does things now, the key is to change your business processes to fit the standard way the system does things. 

The business needs to challenge their current ways of working and really understand where their inefficiencies are. 

This can be an uncomfortable undertaking depending on how receptive the business users are to change. Users may feel like you are critcising them, that the suggestion is that they aren’t doing a good job or doing things well,  that they are inefficient and should be doing things better. 

This really isn’t the case, this is just the perfect opportunity to challenge the status quo and make changes for the better.

Users can often be difficult to convince that the ERP best practice solution will work for them, they’ll be able to give 101 reasons why they are different. But be patient and try to keep persuading and convincing them, as in reality they often find the best practice processes work just as well if they give them a try and have an open mind. 

Development time and effort should be concentrated on the things that the standard ERP system may not deliver, or the things that make your business stand out from the rest. The processes that add value to your business or help you to reduce costs.

Once your design is complete and documented, the Blueprint should be reviewed and signed-off by the project stakeholders to agree that it meets their objectives.


Now we have a clearly defined scope we can move onto the system build.

This is where we configure, customise and build the ERP system to meet the individual business requirements. Configuration and customisation are key components of any ERP build and fitting the system to your business environment. 

Every ERP system needs to be configured to meet the specific business requirements. Configuration means setting up the standard ERP system to work for the individual business.

For example, defining your enterprise structure, defining languages and time zones, setting up custom fields, defining roles etc. 

Configuration takes the standard system and ‘tweaks’ it to make it unique to your business, you extend the standard functionality but still continue to use the standard code delivered with the system.

Customisation or development is the process of changing the standard ERP system and enhancing it with a unique business requirement. 

This includes modifying or enhancing standard features, adding new features, building interfaces between systems, changing standard screens or reports. 

When we customise our ERP system we make a conscious choice to create an ERP solution that is unique to our business

In essence we modify the programming code delivered as standard with the system.

ERP configuration and customisation work together to make an ERP application function, however, as we pointed out earlier the more customisation or development you have within your ERP system the more unique the solution becomes to you and the more costly and complex the solution becomes.

To customise or not to customise. Every change or development made to the standard code adds cost to the project. It adds costs now but also can add additional costs over time through support and future developments.

Customising may enable you to correct a perceived system deficiency that matches your business needs perfectly, but you need to have the skills to define how it should work and to write the code to support it. You need to be able to define what happens in different scenarios and determine where the data sits within the database structure so that the developer can extract it to use in the code. You need to define what happens when it goes wrong, how errors should be dealt with. This takes knowledge and knowhow to define and build.

Sometimes it’s a straightforward piece of customisation that’s easy to achieve and can be done quickly, sometimes it’s a highly complex piece of code that takes weeks to define and deliver. When your ERP system is patched or upgraded your standard configuration will work, this will be guaranteed by your ERP vendor, and if it doesn’t they will fix it for you. 

On the other hand there’s no guarantees with your customisation. There’s a chance it might not work in future releases and enhancements of the system, and because it’s not standard code delivered by the ERP developers they won’t provide a fix to get it working, so you’ll need someone on hand who can fix it. This is something you need to consider.

That’s not to say that customisation is taboo but it does introduce cost and risk to your ERP system.

Think long and hard as to whether it’s really needed, once the floodgates have been opened there’s a tendency for customisations to get out of hand, what’s another one in the whole scheme of things?

Think about why the customisation is needed and the business benefits of it. Ideally customisations should support a  business driver such as reducing costs or increasing revenue, not just because someone thinks it might be nice and would make their lives easier.

If you need a multitude of customisations maybe you’ve chosen the wrong ERP package for your business.

Once all our configuration is in place to support all the business processes outlined in the blueprint, and any customisations identified have been defined and developed our system build is complete and we are ready for testing.


An important part of any ERP implementation is the testing of the system. 

We need to ensure that the ERP solution that is being rolled out is robust and fit for purpose from a business perspective. 

Does the solution fit our requirements and do what we want it to do?

There are many different aspects and phases of testing throughout the lifecycle of your ERP project, all of which have different goals. 

As you would expect each ERP product, supplier and indeed project will have its own language and terminology in relation to the various testing that’s required. 

It doesn’t really matter what each of the test phases are called as long as everyone uses the same terminology and the meaning is consistent to everyone, they all understand it to mean the same thing.

The following are examples of the types of testing that will be executed during the lifecycle of the project but also ongoing through the lifecycle of your ERP system.

A smoke test, is a short test carried out by the functional development team to validate that the environment has been built correctly, code and configuration changes have been applied and formal testing may commence.  

It enables the team to verify critical functions are operational like the availability of the application.

This testing focuses on stability rather than functionality and is executed as a prerequisite to functional tests.

Unit testing is carried out by the system developers and is the testing of an individual function or business process. 

The purpose of this testing is to validate that each piece of configuration or code performs and functions as expected.

The project team is responsible for ensuring that unit tests are defined and executed with the desired outcome. 

System Integration Testing (SIT) is executed by the project team developers, but rather than testing individual processes, it links together multiple processes and tests the end to end business process to ensure that they are working as expected. SIT testing is executed in a more formal environment with a larger more robust dataset, to give a more realistic business process test. 

It includes testing the connectivity and communication between different systems that might be used as part of the end to end business process for example, your ERP system and payroll system. 

This may also cover specific scenarios or string testing that is unique to a specific set of circumstances for example a certain customer, a specific product line or set of services that are offered.

User Acceptance Testing is the responsibility of the business to define and to execute. This is their chance to really get to grips with the system and understand how the new ERP system works. This is their opportunity to ensure that the system satisfies their detailed business requirements. 

They need to ensure that the system is fit for purpose and that it can support the business processes.

If done correctly UAT is a much more comprehensive cycle of business testing, in an environment that provides a larger and more robust dataset and enables true simulations of business processes.

Through UAT the business users are trying to ensure that the system processes are in place to support their day to day activities. This also helps them to shape how their daily lives may be impacted and implement any process or procedural changes that are required to support the new ERP system.

One key element of UAT which is often overlooked is to introduce an element of negative testing to ensure that the system under test can gracefully handle invalid input or unexpected user behaviour to confirm that the system is robust and can handle non standard input.

The vast majority of business users have probably never been involved in UAT or know what it entails. 

As such being clear on what they need to do and what they are looking to achieve is of paramount importance. Far too often users execute the same tests as the developers have executed during SIT which really serves no purpose.

As part of UAT the users should be trying to ‘break’ the system. This aims to ensure that as many defects as possible have been fixed before the system ‘goes live’ and that the system truly does what the business needs. The better and more robust your UAT testing is the better the end ERP solution will be.

Non functional testing can cover a multitude of activities depending on the non functional requirements defined by the business. 

It explicitly tests the non functional parameters that are never addressed by the functional testing, things such as system performance, system reliability, accessibility from different platforms and devices, backup and disaster recovery procedures.

Types of non functional testing may include:

  • Stress / Load / Performance / Volume Testing; i.e. checking if system response times are acceptable, whether periodics processes run quickly enough and the number of concurrent users that can be supported is sufficient.

  • Usability testing; i.e. how intuitive the system is to navigate around and how easy it is to perform a function. Validating the consistency of screens and interfaces in terms of look and feel.

  • Authorisation and security testing; to ensure that staff have access to the transactions that they need to do their role but that there is no conflict of interest in terms of segregation of duties.

As with any theatrical performance the dress rehearsal is the practice that ensures everything is perfect for the opening night or in our case the ERP cutover weekend.

The dress rehearsal enables the project team to practice and refine the cutover activities that are required for the final cutover of the system into the live business environment. This is the opportunity to refine the plan, to iron out issues and to get accurate timings for the go live weekend. 

It may involve setting up a ‘war room’ to coordinate activities and ensure everyone knows what they are doing and when.

Lessons learnt from the dress rehearsal should be fed into the cutover activities for the go live weekend to ensure this runs as smoothly as possible. 

Some projects carry out what they refer to as Day in the Life testing. This effectively simulates a regular business day in the new ERP system but in a Production like test environment. 

Real users using real data, real data volumes, real interfaces and job execution to simulate real business processes.

Depending on the type of ERP project in flight it may be relevant to carry out some kind of regression testing. This testing is carried out by the business users. For example, if you are already running an ERP solution and the project is to change or add a significant piece of new functionality, you want to ensure that none of the existing business processes are adversely impacted and no longer work.

There are various goals of testing:

  • To verify that the system is robust and fit for purpose.

  • To instil confidence within the business that the ERP solution fits the business needs.

  • To ensure that from a functional perspective that all the required business processes can be executed and that there are no gaps.

  • To identify any system or solution defects that need to be resolved.

  • To validate the integrity of the system within the various constraints of the business controls defined.

Test execution and management of test execution within the project can vary from manual to semi automated to fully automated depending on the size and scale of the project.

Manual testing involves a human writing and executing the test scripts in the system manually to check all the features of the ERP solution. They record and store the outputs of testing, results and reports manually without the help of any automated software tools. 

With automated testing, the testers write code or scripts using automation tools that allow the features of the ERP solution to be executed and tested automatically. 

Testers use automation tools to run pre-defined tests to compare the actual and expected results to determine whether the test has passed or failed, and whether the solution is working as expected. Test automation enables you to execute repetitive tasks without manual intervention.

Although test automation requires additional up front effort in terms of script definition and may also require some specialist skills to define the scripts initially or train the team, the ultimate aim is to reduce the test cycle and the amount of human effort required, enabling the execution of testing in a shorter period of time.

There are loads of different test automation tools on the market which can aid the process.

The pros and cons of test automation can be debated and both manual and automated testing have their place, it’s up to the project to determine the approach that suits them.


In order for the ERP system to successfully go-live it is inherent that the cutover and data migration activities are carefully planned in advance.

The cutover strategy document outlines the approach, milestone dates, activities and deliverables that have been agreed in order to achieve a successful cutover.

The cutover plan contains the carefully orchestrated steps that are required in order to seamlessly transition the business from the legacy system to the new ERP system. Depending on the organisation, it may take a few hours or it may take days.

It considers breadth, criticality and timing and plays a central role in mitigating the business risks associated with the implementation.

Cutover planning starts very early on in the project, in the initiation phase with the creation of the cutover planning strategy document.

This document outlines the guiding principles and the approach that will be taken. It is further developed into a cutover plan as the project develops.


Some master data will have already been created in the new ERP system, subject to a change freeze, however after the legacy system has been shut down, transactional data will need to be extracted, subjected to conversion and then uploaded into the new system by a method called Data Migration.

This data migration activity will have been carefully planned, decisions will have been made on what exactly to carry across to the new system.

For example, decisions will have been made around whether to migrate financial records older than the statutory age (in the UK it's 7 years).

The business may choose to retain this data on the old system, converting it in effect to a lookup system.

For the new ERP system, decisions will have been made on what will require new data creation or what data will have been converted.


The decisions that ultimately lead to the agreement of what data remains and what is carried across will normally lead to data cleansing activities.

If your business has been operating for a number of years, customers may exist in the old system that are no longer trading, it wouldn’t make sense to move those records across.

As part of the project the data would be assessed or cleansed, it may be marked for migration or it may be deleted.

These decisions require early agreement in the project, the data being cleansed throughout the project lifecycle most commonly by business people assigned to the project.

It is critical that the business takes ownership of the data and the responsibility is not left to the project team.

The business must own their own data and take responsibility for maintaining the integrity and usefulness of that.


In order for the ERP system to successfully go-live it is inherent that the cutover and data migration activities are carefully planned in advance.

The cutover strategy document outlines the approach, milestone dates, activities and deliverables that have been agreed in order to achieve a successful cutover.

The cutover plan contains the carefully orchestrated steps that are required in order to seamlessly transition the business from the legacy system to the new ERP system. Depending on the organisation, it may take a few hours or it may take days.

It considers breadth, criticality and timing and plays a central role in mitigating the business risks associated with the implementation.

Cutover planning starts very early on in the project, in the initiation phase with the creation of the cutover planning strategy document.

This document outlines the guiding principles and the approach that will be taken. It is further developed into a cutover plan as the project develops.

Data migration is the process of moving data from the existing system/ systems into the new ERP system.  There are 3 main steps in the data migration process:

Extract – download the data from the existing system(s)

Transform – make any changes to the extracted data that are needed in order to load it into the new system.  An example of this could be if the customer numbers in the old system are 10 characters long but they need to be 12 characters in the new system, the existing data would need to be transformed to add the extra 2 characters.

Load – take the transformed data and load it into the new ERP system.

There is an additional step called Data Cleansing. 

Data Cleansing can be done either before the Extract from the old systems or a part of the Transformation process.


The cutover team and data migration teams work very closely together as their activities are intrinsically linked.

The cutover team cannot write the cutover plan without key input from the data migration team and vice versa the data migration team is dependent on the cutover team orchestrating the business activities.

On some projects the teams are separate but on other projects the team acts as one. There is no right or wrong way, the decision is made at the start of the project and is often dependent on the scale and complexity of the project that is being implemented.

What happens during cutover?

The primary task for cutover is to ensure that all stakeholders are informed, which is generally managed by working closely with the Change management team who are responsible for managing communications and ensuring consistency in communications throughout the project.


In order to cutover from the legacy system to the ERP system the business will need to halt some, if not all (depending on how much of the business is dependent on the operating system) of the business activities.

These tasks may include shutting down production machines, putting a temporary stop to deliveries, sending out the last invoices and closing down financial activities in the legacy system.

As financial activities are critical business processes it’s usual for a go-live to take place either at a month end or a year end in order to coincide with finalising financial activities. This is not always the case, but it is common practice.

Once business activities have ceased access to the legacy system is restricted only to the data migration team. Interfaces are stopped to prevent in and outbound flow of messages with business partners during the cutover period.

After confirmation from the business to proceed this is where the data migration team starts to work. The extraction of the required data from the legacy system starts, its translated into the new format and a test and a test conversion load is executed in order to verify the cutover process.

The business team will verify the data load and provide sign off to proceed. Data is loaded  into the new ERP Production system and the preliminary checks are done in the new system. The business is critical in providing the final sign off and interfaces will be switched back on.

The business will then start the go-live activities.


Once the system has completed cutover and data has been migrated, it is essentially live, and is handed to the business for the ongoing go-live activities.

Go-lives can be staggered so the critical activities will resume immediately such as bank payments and financial transactions, however other activities such as production or distribution may be started slowly then ramped-up as the business gains confidence in using the new system.

This is called a ramp-up plan and it’s used to control activities in the first stages of go-live to ensure that there are no defects, or if there are they are quickly detected and fixed whilst the transactional volumes are low.

It’s a way to mitigate risk after go-live and to control the flow of goods or services through the business during the first week of go-live.


In the Introduction to ERP Projects section we mentioned that there are different strategies considered for go-lives.

Depending on the strategy chosen, the go-live could be a “BIG-BANG” approach, so all business units go live at once, or other methodologies could be considered such as a series of staggered go-lives depending on geography, business unit, complexity and so on.


Once a system goes live, more often than not the risk of rolling the system back to the legacy system is greater than fixing the newly implemented system that is live.

However, on occasion things do go wrong and all eventualities need to be considered.

The business and project teams need to agree a roll back plan, so in the event of a catastrophic failure, the business could revert or roll back to the previous system.

In the same way, business continuity plans should be reviewed in the event that they are needed.

The business should already have BCPs in place but the validity of those should be reviewed prior to go-live and they should be on hand in case they are required.

Go-live and ramp up activities typically are short lived, with a duration of less than one week and the business will be up and running at capacity at the end of this period.

At the end of this period the business will then transition into the final project state which is hypercare or post go-live support.


You've might have spent millions on your ERP project. But it counts for nothing if people don't use it.


What is ERP Adoption?