ERP Implementation Partner: How We Sequenced a Modular Cloud ERP Rollout for a Building Supply Distributor
By Ed Hitchcock, Enterprise AI Systems Architect, SupplyTech Solutions
When a building supply distributor reached out about replacing their core platforms, they had already lived through one failed ERP project. A previous vendor tried to lift and shift their legacy system to a cloud suite in a single 18-month program. It collapsed in user acceptance testing. They lost roughly $1.4M and 14 months of leadership attention. By the time we got the call, the executive team was skeptical of any pitch that started with the words "ERP rollout."
We were brought in as their ERP implementation partner, but the assignment we accepted looked very different from what most firms would have proposed. We were not there to swap one platform for another. We were there to sequence a modular cloud ERP rollout that would not break the business along the way. This post walks through what we did, what we deliberately did not do, the architecture, and early results from the first two modules going live.
The Client and the Starting Point
The client is a regional building supply distributor running roughly $180M in annual revenue across 6 branches in the Mid-Atlantic and Southeast. About 230 employees serving professional contractors, lumberyards, and a small dealer network.
Their technology stack at the start of our engagement looked like this. A heavily customized legacy ERP from the mid-2000s, running on-premises, with most reporting handled in Excel exports. A separate CRM that sales used inconsistently. A warehouse system that was effectively a barcode scanning shell on top of the ERP. No transportation management system. Procurement happened in the ERP, in spreadsheets, and over the phone, depending on the buyer.
The CFO described the state plainly. They had data in a lot of places, and none of it agreed with itself. Closing the books took 12 to 14 days. Pricing decisions for large bids took 24 to 48 hours because nobody could pull a clean margin view by customer and product line in less than a day of analyst work. New branch onboarding took 9 to 12 months of dedicated effort to get the legacy ERP configured to match local workflows.
Why This Engagement Needed a Different Kind of ERP Implementation Partner
Most ERP implementation partners come in with a fixed methodology, a fixed module set, and a fixed timeline. Pick the suite, sign the licenses, run discovery, go live in 12 to 18 months. That model is what burned this client the first time. It assumes the business can absorb a complete platform replacement in one motion. For a distributor with thin margins and tight cash conversion cycles, that assumption is dangerous.
We proposed a different model. Modular cloud ERP, sequenced over 24 months, with each module landing on top of the foundation work from our earlier phases. We had already done Phase 1 (process documentation and should-cost modeling) and Phase 2 (knowledge management system) with this client over the prior 8 months. The ERP did not have to be the system of record for everything on day one. It had to integrate with what we had already built.
The platform we selected was Microsoft Dynamics 365 with the Supply Chain Management modules layered in over time. We started with Finance and CRM, then sequenced OMS and WMS, with TMS and advanced procurement planned for later waves. Each wave runs 4 to 6 months end to end, including parallel testing and side-by-side cutover.
The Sequence We Actually Ran
The full roadmap spans 24 months across three waves. We are 11 months in and 1.5 waves complete. Here is what each wave looks like.
Wave 1 (months 1 through 6): Finance and CRM. We replaced the legacy GL, AR, AP, and customer master with D365 Finance, and the standalone CRM with D365 Sales. This wave was deliberately chosen first because it had the smallest operational risk. If the GL is wrong for a day, the business still ships product. If the warehouse system is wrong for a day, trucks stop. We wanted the team to build confidence on the lower-risk module before touching the higher-risk ones.
Wave 2 (months 5 through 11): OMS and WMS. Order management and warehouse management came in next. We ran the new modules in parallel with the legacy warehouse system for 8 weeks, then cut over branch by branch over 6 weeks. By month 11, all 6 branches were live on D365 OMS and WMS.
Wave 3 (months 12 through 24, planned): TMS, advanced procurement, and the dealer portal. Transportation management replaces a mix of phone calls and spreadsheets. Advanced procurement adds demand forecasting and supplier scorecards on top of the existing buyer workflow. The dealer portal gives the dealer network self-service order entry, which today goes through email and phone.
The sequencing decision was the single highest-leverage call we made on this engagement. The previous failed project tried to do all of this in parallel, which is why it collapsed in testing. By sequencing, we kept the change load on any individual team to roughly one major module per 6-month window.
The Architecture and What We Integrated
D365 sits in the middle of the stack, but it is not the only system of record. That distinction matters for any ERP implementation partner who has worked in mid-market distribution. The architecture has four layers.
At the data layer, D365 Finance, Sales, OMS, and WMS hold the transactional data. Customer master, item master, GL, inventory positions, open orders, and warehouse movements all live in D365.
At the knowledge layer, the SharePoint Premium based knowledge management system we built in Phase 2 holds the documented processes, SOPs, branch-specific exception rules, and supplier reference data. D365 calls the KMS for context when needed (for example, when a buyer pulls up a supplier record, the linked KMS article surfaces in a side panel).
At the workflow layer, Power Automate orchestrates the cross-system steps. About 22 flows today handle things like new customer onboarding (CRM creates customer, triggers credit check, opens credit application, syncs to D365 Finance), purchase order approval routing, and exception notifications when an order is held in OMS.
At the integration layer, Azure Logic Apps and a small set of REST endpoints handle the connections to the systems we did not replace. The legacy ERP still runs in read-only mode for historical lookups during the transition. The accounting team's reporting tool (a third-party FP&A platform) connects to D365 Finance via a scheduled data export.
We deliberately kept the integration layer small. Every connector we add is something we have to maintain. The principle we run with is: if a system can be replaced by D365 in a future wave, do not integrate it; deprecate it instead.
What We Did Not Do
Three decisions stand out, and they are the ones that distinguish what we delivered from what a traditional ERP implementation partner would have delivered.
We did not customize D365 at the code level. Every workflow that did not match D365 out of the box was either configured with native tools or handled by a Power Automate flow sitting outside the ERP. No custom .NET extensions, no third-party ISV add-ons that lock the client into a specific upgrade path. The total customization surface area is roughly 8% of the deployment, all in Power Platform components that are independently maintainable.
We did not retire the legacy ERP on cutover day. It runs in read-only mode for 18 months post-go-live so that historical data, audit trails, and edge-case lookups remain accessible. The cost to keep it running in read-only mode is roughly $4K per month, which is trivial compared to the risk of trying to migrate 12 years of historical data perfectly on day one.
We did not push for a big-bang training program. Training was role-scoped, delivered in 90-minute sessions per role, and reinforced with embedded Copilot Studio prompts inside D365. The new-hire onboarding curriculum was rewritten alongside the rollout, so by month 9, new hires were learning D365 native instead of legacy first.
What We Measured in the First 11 Months
The metrics below reflect the post-cutover state for Waves 1 and 2. Wave 3 is in design.
Book close moved from 12 to 14 days down to 5 to 7 days. The CFO's team attributes most of the gain to native GL automation and the elimination of manual subledger reconciliations.
Branch onboarding (the time to get a new acquired branch operational on the platform) moved from 9 to 12 months to roughly 10 to 14 weeks. The biggest driver was that D365 configuration is now templated, and our Phase 2 KMS holds the playbook.
Quote-to-margin analysis (the time to produce a clean margin view by customer and product line for a large bid) moved from 24 to 48 hours to roughly 30 to 90 minutes. The Power BI semantic model on top of D365 made this possible.
Order entry time for the inside sales team moved from roughly 9 to 12 minutes per order to 4 to 6 minutes per order, driven by the integrated customer and item search inside D365 Sales.
Warehouse pick accuracy improved from approximately 96.5% to 99.1%, measured over the first 90 days after WMS cutover at branches 1 through 4. Branches 5 and 6 are too early to report.
Total engagement cost across the full ERP wave program (Wave 1 plus Wave 2, services only, excluding licensing) came in at roughly 0.9% of revenue. The previous failed program had burned approximately 0.8% of revenue before being canceled, so the client effectively rebuilt the program at parity cost and got working systems.
Why This Sequence Matters for Anyone Picking an ERP Implementation Partner
The lesson from this engagement is not that Dynamics 365 is the right platform for every distributor. It happened to be the right fit here because the client was already heavy on Microsoft 365 and Azure, and the SCM modules covered their distribution use cases without a separate WMS vendor. The lesson is that the sequence matters more than the platform.
A modular cloud ERP rollout that respects the operational risk profile of each module, that integrates with existing systems instead of demanding immediate replacement, and that runs on top of documented processes and a working knowledge layer, has a fundamentally different success profile than a single-shot platform swap. Every ERP implementation partner conversation should start with the question of how much change the business can absorb in a 6-month window. Most cannot absorb a full platform replacement in that window. Most can absorb one well-sequenced module.
We will publish Wave 3 results when TMS and advanced procurement are live. The dealer portal is the piece we are most curious about. It puts the ERP outside the four walls of the company for the first time. That is where modular cloud ERP earns its keep.
Comments