- Phase 0 is the discovery and design work at the front of an implementation, carved into a standalone fixed-fee engagement with a stopping point at the end.
- Nothing is configured; the output is a documented current state, a designed future state, and a fixed-fee build proposal priced against confirmed scope.
- The documentation is written to be vendor-neutral, so it stands on its own for any qualified Microsoft partner.
- Four to six weeks of structured workshops routinely surface entity structure, data quality, and integration count issues that would otherwise become change orders in week three.
- If you sign the implementation with us within three months of Phase 0 closing out, 100% of the Phase 0 fee is credited toward the project.
A couple weeks back, a finance lead at a consumer packaged goods company put a question to us she'd been asking every vendor in her process: if she connected her systems point to point now, then moved to middleware later as more trading partners came online, would she end up paying to build the same integrations twice?
She wasn't asking for a price. She was asking for an architecture decision, and she told us she hadn't been able to get a clear answer from anyone yet. That's a reasonable place for her to be. The answer depends on how many trading partners she'll be running in three years, how her brands are structured legally, and which parts of her process have to survive contact with a co-packer. None of that fits inside a sales call.
That gap is what Phase 0 exists to close.
What Phase 0 is
Phase 0 is the discovery and design work that sits at the front of any serious Dynamics 365 implementation, carved out into a standalone engagement with a fixed fee and a stopping point at the end.
Nothing gets configured. The output is a documented design: how your business runs today, how it will run on the new platform, what data moves and in what condition, who can see what, and what the build involves. Then everyone pauses and decides what to do next.
Two things come out of it. The first is a documentation set detailed enough that you can hand it to any qualified Microsoft partner and get a fixed-fee quote back without much fuss. That's deliberate. The design is written to stand on its own, including the platform recommendation, so it doesn't quietly lock you into one product or one partner. The second is our own fixed-fee proposal for the implementation, priced against a scope we've confirmed rather than one we've estimated around.
If you sign the implementation with us within three months of Phase 0 closing out, we credit 100% of the Phase 0 fee toward the project. The intent is that you don't pay twice for the same work.
Why a fixed fee comes after discovery rather than before
We've pulled our own fixed-fee option off the table before. On one project we had priced a marketplace connection as a routine custom integration, which is a common pattern and not a heavy lift on its own. Reading the client's requirements workbook more carefully surfaced enough additional trading partners that the right answer was probably middleware, not a set of one-off connections. Three or four of those changes the shape of the whole build.
We could have priced around that uncertainty. What that produces is a number padded with contingency, followed by a project that runs on in-scope and out-of-scope conversations nobody enjoys having. Phase 0 is the mechanism that earns a fixed fee instead of guessing at one.
What four to six weeks look like
Phase 0 runs as a series of structured workshops, organized by business workstream rather than by software module. A recent engagement for a multi-entity operations business ran 10 workshops and logged 47 confirmed design decisions:
| Workshop | Who's in the room | What comes out |
|---|---|---|
| Executive objectives and governance | Executive sponsor, leadership | Strategic priorities, governance model, success criteria |
| Customer lifecycle and sales | Sales leadership, account managers | Lead-to-close workflow, pipeline design |
| Service operations | Operations manager, dispatch | Work order lifecycle, scheduling logic, service levels |
| Field execution | Field leads, technicians | Mobile workflow, contractor access, offline requirements |
| Inventory and procurement | Inventory manager, purchasing | Item setup, purchase order workflow, receiving, valuation |
| Finance and close | Controller, finance team | Chart of accounts, entity structure, period close controls |
| Data and integrations | IT, system owners | Legacy system inventory, integration design, migration scope |
| Design playback | Cross-functional | Confirmed decisions, open items resolved |
The time commitment lands on your people, and it's worth planning for. On a comparable engagement it worked out to roughly four to six hours each for most function leads, and eight to 10 hours for the internal IT lead, who tends to carry the heaviest load because they're the one who knows where the systems are.
What you walk away with
Six documents, and all of them are yours:
- Solution Design Document. Current-state assessment, systems inventory, pain points, data quality findings, and the future-state design for every workstream, including integration architecture, environment strategy, and data migration approach.
- Data Dictionary and Entity Relationship Diagram guide. Field-level detail for every core entity, the relationships between them, status models, and master data standards. This is the piece that makes the package portable to another partner.
- Security Role Matrix. Role-by-role access across the platform, with segregation of duties controls and license mapping.
- Project Plan and RAID log. The Phase 1 schedule, milestones, and the running register of risks, assumptions, issues, and decisions.
- Executive Summary presentation. A short leadership-facing readout for sign-off.
- Implementation proposal. Fixed fee, defined scope, timeline, and resourcing.
What discovery tends to turn up
The findings are rarely dramatic, and they're almost always expensive if you meet them mid-build instead.
On one recent engagement, roughly 30% of the client's asset records were missing serial numbers, installation dates, or location assignments. Customer records were duplicated across the legacy CRM and the accounting system. The chart of accounts differed across all three legal entities and had to be harmonized before Microsoft Dynamics 365 Business Central setup could start. Discovery also turned up a customer-facing storefront, a custom internal portal, and a shipping platform that weren't in the original picture at all. Every one of those became a client action item with an owner and a due date, resolved before Phase 1 started rather than during it.
On another, two people at the same company answered the same discovery questionnaire and described two different companies. One described two legal entities. The other asked for three product brands, each carrying a full profit and loss statement and balance sheet. Whether those brands become separate Business Central companies or dimensions inside one company is the single largest driver of finance configuration effort in the project, and it's a question the client hadn't yet resolved internally.
When you don't need one
Plenty of projects go straight from a ballpark to a proposal, and they should. A single-workstream build, one legal entity, few integrations, and requirements the team can already articulate doesn't need a design phase bolted on the front.
Phase 0 earns its place when the platform question is still open, when the integration count is high enough that the architecture pattern itself is undecided, when the legal or brand structure hasn't been settled, or when you want a fixed fee on the build and someone has to do the work to make one meaningful.
If you're somewhere in that territory and want to talk through whether a design phase would help or just add a step, bring us the messy version. That's the useful one.