ERP Project Step by Step: From Discovery to Go-Live

Short answer:

A typical ERP project moves through 6 stages — discovery, process analysis, solution architecture, team assembly, implementation, and knowledge transfer — and takes 2 to 6 months depending on scope. The number-one cause of delays isn't the software; it's unpreparedness on the client side: dirty data, unreachable decision-makers, and key users given no time for the project. This article explains what happens at each stage and — the part most guides skip — what's expected from you.

Author: Bugra — 6 years as a consultant and project manager on ERP projects. The staging below is the actual methodology we use in our projects.

Stage 1: Discovery

What happens: We discuss your company, goals, current systems and growth plan. The aim isn't to talk software but to understand the business — the "which program?" question is deliberately postponed at this stage.

Expected from you: The decision-maker (owner/GM) personally at the table. Projects where only the IT lead attends discovery later stall in "that's not what management wanted" crises.

Duration: 1–2 meetings.

Stage 2: Process Analysis & Demo

What happens: We map your workflows department by department — systems used, data movements, bottlenecks. The results of the analyses will be used to create demos with data similar to yours. Key users will be tested on these screens to see if they can do everything they could in previous systems, and even better. The output is concrete: a process map, a bottleneck list and an improvement-opportunities report.

Expected from you: Key users (warehouse lead, accounting chief, sales manager) genuinely participating — and speaking honestly. Sentences like "the system shows it this way, but here's what we actually do" are this stage's gold mine; if hidden, the project gets built on the wrong foundation. And you also need to convey all the situations you might encounter in the demos following the process analysis during the analysis phase and to mention them in the demo phase as well.

Duration: 1–3 weeks depending on company size.

Stage 3: Solution Architecture

What happens: Based on the analysis, the right technology combination is designed: which process runs on the ERP's standard, which needs an add-on module, which an integration, which a custom development. We pick what fits you, not what's trending.

Expected from you: Investing time in scope decisions now. A 1-hour scope discussion at this stage is cheaper than a 1-week revision during implementation.

Duration: 1–2 meeting.

Stage 4: Building the Right Team

What happens: Specialists are assigned to the project's needs: ERP consultant, developer, integration expert. In our model this team is coordinated from a single point — you work with one counterpart, not five separate vendors.

Expected from you: Appointing a project owner on your side: someone with authority, availability and dedicated weekly hours. The "everyone's sort of involved" model means no one is.

Duration: Runs in parallel with architecture.

Stage 5: Implementation

What happens: Installation, configuration, data migration, integrations and testing. Good projects move in waves, not a "big bang": core modules first in a test environment, go-live only after key-user sign-off. The old system lives in parallel until the new one is verified.

Expected from you: Two critical things. First, data cleaning — if duplicate customer records and dead inventory items get migrated, distrust is born on day one. Second, testing discipline: key users must actually run the test scenarios, never approving "all good" without seeing the screens.

Duration: 3 weeks – 3 months depending on scope. The longest stage.

Stage 6: Knowledge Transfer and Continuous Improvement

What happens: Training, user documentation and video guides are delivered. Our target is 100% knowledge transfer: you should be able to run the system without depending on us. Intensive support follows go-live for the first weeks; after that, an optional improvement cycle.

Expected from you: Taking training seriously and collecting feedback in the first month after go-live. Systems create value when used, not when installed.

Duration: 1–2 weeks intensive + ongoing.

The 5 mistakes that delay projects the delayers we see over and over:

1. Trying to go live with dirty data

2. Giving key users no time for the project — an employee with the project stacked on top of their day job fails at both

3. Growing the scope mid-implementation ("while we're at it, let's add...")

4. The decision-maker disappearing — accumulated decisions stall projects for weeks

5. Cutting training.

   
   

   What all five share: none of them are about the software; all of them are about preparation and ownership.

The right start

Notice that the first two stages — discovery and process analysis — are entirely software-independent. Good news: we offer exactly this start as a free process analysis. In 60 minutes we review your current setup and give you, in writing, whether you're truly ready and a realistic time/budget range. Even if we never run the project, you keep a map of where to begin.

👉 [Book Your Free Process Analysis] (For English & Turkish for now)

Frequently Asked Questions

How long does an ERP project take in total? 2 months for a simple scope, 3–5 months for a typical SME project, 6–12 months when production planning is involved. The biggest variable isn't the software — it's data readiness and the time your key users can commit.

Will our daily operations suffer during the project?

Not in well-planned projects; intensity rises during key users' testing and training weeks. Scheduling those weeks outside your seasonal peak is the simplest and most effective precaution.

When is the best time to go live?

The start of a fiscal period (new year, new quarter) gives the cleanest accounting transition — but going live in February with clean data always beats rushing to January 1st with dirty data.

Are we locked into support after the project?

Not in our model — with full documentation and knowledge transfer, you can run the system independently. Support and continuous improvement should be a choice, not an obligation; be careful with vendors who write dependency into the contract.