How much of Sales to turn on in phase one

What it does

Dynamics 365 Sales arrives with far more switched-off capability than any first release should carry: lead and opportunity management, product and price list management, goals and forecasts, productivity tools, the sales accelerator, Copilot, LinkedIn and Teams integration. Phase one scoping is deciding which of those go live on day one and which wait — and defending that line against a sponsor who has seen the demo.

Key facts

Microsoft's implementation guidance names three deployment approaches: big bang (single phase), phased rollout, and parallel rollout.
Phases can be cut by module, by business priority, by business unit, or by geography. Those are four different projects, not one choice with four labels.
Parallel rollout — running old and new systems together with users entering data twice — is described as primarily a validation technique rather than a rollout approach in its own right.
Named big bang risks: adoption and change management pressure, post-go-live issues that are hard to reverse, the whole user community affected at once, and no chance to learn from an early launch.
Named phased risks: longer overall deployment, complex staggered data migration, change fatigue, scope creep as timelines stretch.
Sales app settings group broadly into lead management, opportunity management, product management, productivity tools, Teams and LinkedIn integration, and goals and forecasts.
Release strategy, deployment strategy and environment strategy are distinct things in the guidance — what you ship, where you ship it, and the dev/test/production spaces you ship through.
Premium forecasting cannot produce predictions until there are more than 10 closed opportunities with actual and estimated values and close dates, which rules it out of a phase one on a fresh tenant.
Sales accelerator on Sales Enterprise is capped at 1,500 sequence-connected records per month, which is a scoping constraint as much as a licensing one.

When to use / skip

Phase one is accounts, contacts, leads, opportunities and activities, with one business process flow and a small set of views and dashboards. That is it. Everything else is phase two until proven otherwise. This is unfashionable advice and it is the right advice, because the failure mode of a Sales implementation is never "we did not turn enough on" — it is sellers who never adopted the thing because it demanded twenty fields they did not care about.

The specific things I hold back by default: forecasting (no pipeline history to forecast), goals (nobody agrees the targets until the data is trusted), product and price list management (a data quality project pretending to be configuration), the sales accelerator (needs a defined cadence the client usually has not written down), and predictive scoring (needs closed history). Each of those is a good capability, and each of them is worthless on a system that has been live for a fortnight.

Beyond the core I do include the Outlook app, because email tracking is the highest-value habit to establish early, and Teams chat, because it costs nothing and makes the system feel like part of the day rather than another place to go.

Big bang versus phased for Sales specifically: a single sales organisation in one country should generally go big bang, because a phased sales rollout means two pipelines and a reporting mess for months. Multi-country, multi-business-unit clients should phase by business unit or geography, take the longer timeline honestly, and accept the staggered migration complexity. Phasing by module inside one team is usually a mistake — it gives sellers an incomplete tool and invites them back to the spreadsheet.

Parallel running is the one I push back on hardest. Asking sellers to enter every deal twice for three months guarantees the second entry is worse than the first, and it lets a weak testing effort pass undetected. Use it as a validation technique for a defined window on a defined subset, or not at all.

Configuration decisions

The phasing axis: module, business priority, business unit, or geography. Pick one and hold it.
The minimum viable release definition — which specific tables, one process flow, and how many mandatory fields a seller must complete to save an opportunity.
Whether product and price lists are in scope, or whether opportunities carry a value with no line detail in phase one.
Which integrations land at go-live versus later, remembering the Outlook app is a deployment task with its own mailbox dependencies.
What the trigger is for phase two: a date, an adoption metric, or a data volume threshold such as enough closed opportunities to make forecasting viable.

Gotchas

Scope creep in a phased rollout is named as a risk for good reason. Every month of extra timeline invites another request, and the phase two list quietly becomes the phase one list.
Staggered migration is harder than it sounds. Accounts shared between a live business unit and one still on the old system need an ownership rule agreed before the first cutover, not during it.
Turning on the sales accelerator without a written cadence produces sequences nobody follows and burns Enterprise capacity while doing it.
Forecasting demoed at pre-sales sets an expectation that it exists at go-live. Correcting that late reads as descoping, even when it was never scoped.
Parallel running masks training failures. Users lean on the old system, adoption numbers look acceptable, and the problem surfaces the week the old system is retired.

Consultant notes

Write the phase two list down in the kickoff and share it. A visible parking area for good ideas is the cheapest scope control there is.
Demo the phase one scope, not the product. If a sponsor sees the sales accelerator in a pre-sales demo, name it as phase two in the same breath.
Push back on mandatory fields. Every one added in phase one is a reason for a seller not to create the record at all.
Agree the phase two trigger in writing — "when we have a quarter of closed opportunities" is a better answer than a date, and it makes the forecasting dependency obvious.
Before go-live, confirm the environment and release strategy actually match the phasing you promised. That mismatch surfaces at the worst possible moment.

Worth another look after the next release wave, or if Microsoft moves capability between the phase one and phase two lists.