What Happens Between Signing an ERP Contract and Actually Going Live? A Timeline Nobody Talks About

You signed the contract. You shook hands (or clicked DocuSign). The sales team popped champagne, your CFO approved the budget, and everyone agreed: this Odoo implementation is going to transform the business.

Then... silence. Weeks pass. Maybe a kickoff call happens. Some spreadsheets get shared. And slowly, that familiar dread creeps in: What exactly did we just pay for? And when does something actually happen?

That gap between "signed" and "live" is where most ERP projects go off the rails. Not because the software is bad. Not because the vendor is incompetent. But because nobody prepared you for what the middle looks like. This article fixes that. Here's the honest, phase-by-phase breakdown of what happens after you commit to an ERP rollout, how long each stage really takes, and where the landmines are buried.

Phase 1: Discovery and Process Mapping (Weeks 1–4)

This is the part that surprises most business owners. You just bought software, but nobody's installing anything yet. Instead, you're in meetings. Lots of them.

During discovery, the implementation team (whether internal or external) sits down with every department that touches the system. Sales, purchasing, inventory, accounting, HR if it's in scope. The goal is brutally simple: figure out how your business actually runs right now. Not how you think it runs. Not how the employee handbook says it runs. How it really runs, including the workarounds, the sticky notes on monitors, and the "just ask Karen, she knows" processes.

A 2023 Panorama Consulting survey found that 56% of ERP projects experienced cost overruns. The number one cause? Poor requirements gathering during this exact phase. Companies rush through discovery because it feels unproductive. You're not building anything. You're just talking. But skipping this step is like pouring a foundation without checking the soil. It'll crack eventually.

Here's what good discovery actually produces:

• A complete map of your current workflows, department by department
• A gap analysis showing where your existing processes break down or rely on manual effort
• A list of "must-have" vs. "nice-to-have" customizations ranked by business impact
• Clear data migration requirements (what's moving from your old system, what's getting left behind)

If your implementation partner tries to skip discovery or compress it into a single half-day workshop, that's a red flag. Four weeks feels slow. It saves you four months later.

Phase 2: Solution Design and Consulting (Weeks 4–8)

Here's where the blueprint gets drawn. Your implementation team takes everything from discovery and translates it into a technical plan. Which Odoo modules do you actually need? What needs custom configuration? Where do integrations with your existing tools (payment processors, shipping platforms, CRM) come into play?

This phase is where having experienced odoo consulting services makes the biggest difference. A skilled consulting team doesn't just map your requirements to modules. They challenge your assumptions. They've seen hundreds of implementations, so they know which "must-have" customizations will create maintenance headaches in two years, and which out-of-the-box features you're overlooking because your old system didn't have them.

A mid-sized distribution company in the Midwest learned this the hard way. They insisted on replicating their legacy inventory system's exact workflow inside Odoo, including a convoluted three-step approval process for purchase orders. Their consultant pushed back: Odoo's native procurement workflow could handle the same compliance requirements in one step. The company resisted for two weeks before agreeing to a pilot. Result? Purchase order processing dropped from 22 minutes to 6 minutes per order. They almost paid extra to build something worse.

Solution design typically produces a formal document (sometimes called a Functional Requirements Document or Solution Blueprint) that covers:

1. Module selection and configuration plan. Exactly which parts of Odoo you're using and how they'll be set up.
2. Customization scope. What needs to be built or modified beyond standard configuration, with estimated hours for each item.
3. Integration architecture. How Odoo connects to your other systems, what data flows where, and what happens when a sync fails.
4. Timeline and milestones. A realistic project schedule with checkpoints, not just a go-live date.
5. Risk register. Known risks and what happens if things go sideways (because something always does).

If your vendor hands you a timeline without a risk register, ask for one. The teams that plan for problems recover from them. The teams that don't plan for problems become cautionary tales on Reddit.

Phase 3: Data Migration (Weeks 6–12, Overlapping with Development)

Data migration is the phase everyone underestimates. Every single time.

You're moving years of customer records, product catalogs, financial history, vendor information, and transaction data from your old system into Odoo. Sounds straightforward until you realize your old system has 14,000 duplicate customer records, three different product naming conventions (because three different people set them up over eight years), and an accounting structure that made sense in 2016 but hasn't been updated since.

According to Gartner, poor data quality costs organizations an average of $12.9 million per year. During an ERP migration, those hidden data problems don't just cost money. They halt progress entirely. You can't configure inventory management if nobody agrees on what the product categories should be.

Data migration typically breaks down into these stages:

1. Audit and cleanup. Export everything from your current system. Identify duplicates, incomplete records, and outdated information. This is painful, tedious work. It's also non-negotiable.
2. Mapping and transformation. Define how data from your old system maps to Odoo's structure. Your old system called it "Vendor Code." Odoo calls it "Supplier Reference." These translations need to be documented for every field that matters.
3. Test migration. Run a trial import into a sandbox environment. Check for errors, missing records, broken relationships between data tables. Fix them.
4. Validation. Have actual users from each department verify their data looks right in the new system. Not IT. Not the project manager. The people who use this data every day.
5. Final migration. Do it again for real, with the corrected, clean dataset.

Most companies plan for one test migration. Plan for at least two. The first one always surfaces problems you didn't anticipate.

Phase 4: Configuration, Customization, and Development (Weeks 6–14)

While data migration chugs along, the technical team starts building. This phase runs in parallel, and it's where Odoo starts looking like your system instead of a generic demo.

Configuration covers the things you can adjust without writing code. Chart of accounts, user roles and permissions, workflow automations, report templates, email notifications. A surprising amount of Odoo's power lives in configuration, and companies that max out configuration before jumping to custom development save significant budget.

Customization is the code-level work. Maybe you need a custom dashboard that pulls data from three different modules into one view for your operations manager. Maybe your pricing structure is unusual enough that the standard price list feature can't handle it. Maybe you need a specific integration with a niche industry tool that doesn't have a pre-built connector.

The critical discipline here is scope control. Every ERP implementation has a moment, usually around week 8 or 9, where someone in the organization says: "While we're at it, could we also add..." That sentence has killed more project timelines than any technical challenge.

A practical rule that strong project managers enforce: if a feature request wasn't in the Solution Blueprint from Phase 2, it goes on a "Phase 2 list" for after go-live. Not rejected. Just deferred. This single habit is the difference between launching on time and launching three months late.

Phase 5: Testing (Weeks 12–16)

Testing isn't one event. It's three distinct rounds, and cutting any of them short is gambling with your go-live.

Unit testing happens first. The technical team verifies that each module and customization works correctly in isolation. Does the invoicing module calculate taxes right? Does the inventory adjustment trigger the correct accounting entry? These are pass/fail checks against the requirements document.

Integration testing comes next. This is where you check that everything works together. When a sales order is confirmed, does it create a delivery order, reduce inventory, generate an invoice, and update the general ledger? One broken link in that chain, and you've got a mess on your hands post-launch.

User Acceptance Testing (UAT) is the most important round, and the one companies are most tempted to skip. This is where real users from each department sit down with the system and run through their actual daily tasks. Not a demo. Not a walkthrough. They do their jobs in the new system and report what's broken, confusing, or missing.

A manufacturing company in Ohio compressed UAT from three weeks to five days because they were "behind schedule." They launched on time. They also spent the next two months dealing with a production scheduling bug that cost them $45,000 in overtime labor. The five days they saved cost them ten times more to fix.

Give UAT the time it needs. Your team will find things the developers missed. That's the entire point.

Phase 6: Training (Weeks 14–17)

Here's an uncomfortable truth: the best ERP system in the world is worthless if your team won't use it. Or worse, if they use it wrong.

Training isn't a one-hour webinar. For a mid-sized company, expect to invest 20 to 40 hours of training spread across different user groups. Your warehouse team needs different training than your accountants. Your sales reps need different training than your purchasing managers.

The most effective training programs share a few characteristics:

• They use your actual data and your actual workflows, not generic demo scenarios
• They happen close to go-live (training people six weeks before launch means they'll forget half of it)
• They include "cheat sheets" or quick-reference guides for common tasks
• They identify 1 to 2 "super users" per department who become the go-to resource after launch

That last point is critical. Super users are your first line of defense against the post-launch panic that hits every organization. When someone can't figure out how to process a return or adjust a purchase order, they're not calling the vendor. They're walking over to the super user's desk. Invest heavily in those people.

Phase 7: Go-Live and the First 30 Days (Weeks 17–21)

Go-live day is anticlimactic if you've done everything right. And chaotic if you haven't.

Most companies choose one of two go-live strategies. A "big bang" approach flips everyone to the new system on the same day. A phased rollout migrates one department or location at a time. Neither is universally better. Big bang is faster but riskier. Phased is safer but creates the headache of running two systems simultaneously during the transition.

For companies with fewer than 200 employees, big bang usually works if testing was thorough. For larger organizations or those with complex multi-location operations, phased rollouts reduce the blast radius when something goes wrong.

The first 30 days after go-live are the real test. Expect these things to happen:

• Productivity drops temporarily. People are slower in a new system. A 15 to 25% dip in processing speed during weeks one and two is normal. It recovers by week four in most cases.
• "Bugs" that aren't bugs surface. Half the support tickets in the first week will be training issues, not software problems. Someone didn't remember how to apply a discount code or didn't realize they needed to click "Validate" before "Confirm."
• One genuine issue you didn't catch will appear. It always does. The question isn't whether it'll happen; it's whether your team can fix it fast. This is why go-live support (having your implementation partner on standby for the first two to four weeks) is worth every penny.

The Honest Timeline: What to Actually Expect

Putting it all together, here's what a realistic Odoo implementation looks like for a mid-sized company with 50 to 300 employees:

1. Discovery and process mapping: 3 to 4 weeks
2. Solution design and consulting: 3 to 4 weeks
3. Data migration (overlapping): 6 to 8 weeks
4. Configuration and development (overlapping): 8 to 10 weeks
5. Testing (three rounds): 4 to 5 weeks
6. Training: 2 to 3 weeks
7. Go-live and stabilization: 4 to 5 weeks

Total realistic timeline: 4 to 6 months. Not the "8 weeks" some vendors promise. Not the "18 months" that scares you off from starting.

If someone quotes you less than three months for a full implementation, they're either cutting corners or underestimating your complexity. If someone quotes you more than nine months, they might be overcomplicating things (or padding the engagement).

What Nobody Tells You Before You Start

The hardest part of an ERP implementation isn't the technology. It's the organizational change. People have built their careers around knowing the old system's quirks. They've created elaborate workarounds that they're oddly proud of. Telling them "there's a better way now" doesn't feel like a gift. It feels like a threat.

The companies that succeed at ERP rollouts treat it as a change management project with a technology component, not the other way around. They communicate early, involve end users in testing, celebrate small wins during the transition, and acknowledge that the first month will be uncomfortable.

Your ERP vendor can give you great software. Your consulting partner can design a smart implementation. But only your leadership team can create the environment where people actually embrace the change.