F&O implementation in 2026: how the delivery actually works

An F&O implementation in 2026 still follows Microsoft’s Success by Design method: five phases, a Solution Blueprint Review that starts in the first of them, and a Go-live Readiness Review before production. The method has not changed. Where the project runs has. Since 16 February 2026, a new Dynamics 365 Finance, Supply Chain Management or Project Operations customer cannot create a cloud implementation project in Lifecycle Services, and Microsoft’s own regression testing tool is not supported after 15 May 2027, with no other feature replacing it.

So a delivery plan written on last year’s assumptions can be wrong in three places before anyone has configured anything: where the environments live, how production gets released, and how the solution is regression tested after every update. This article walks through an F&O implementation phase by phase, as Microsoft documents it on 26 October 2026, and marks what moved. Cost has its own article, what a finance and operations implementation really costs, as do product choice, in Business Central vs Finance and Operations, and the route from AX, in AX 2012 to Dynamics 365.

The method: five phases and two reviews that are not optional

Microsoft’s Success by Design framework “maps the Dynamics 365 implementation lifecycle into five methodology-agnostic phases: Discover, Initiate, Implement, Prepare, and Operate.” It sits alongside your partner’s delivery method rather than replacing it, and Microsoft recommends it “for use on all Dynamics 365 implementation projects”, whether or not FastTrack is involved.

Two of those reviews are mandatory in Microsoft’s own words. The guidance says to “Make the Solution Blueprint Review a mandatory review for the project”, and describes the Go-live Readiness Review as “also a mandatory review” and “the last stop for assessing any remaining risks before go live.” The Implementation Reviews in between are driven by what the blueprint review finds.

The detail worth checking in any F&O implementation plan is when the first review happens. Microsoft’s guidance is that the Solution Blueprint Review begins in Discover rather than waiting for Initiate, because “Starting the SBR in Discover allows the team to surface architectural risks and alignment gaps early, before design decisions become costly to reverse.” A plan that schedules the blueprint review after the design workshops is reviewing decisions that have already been taken.

Microsoft is also candid that Success by Design “doesn’t guarantee implementation outcomes for customers.” Its own worked example, a Customer Service project rather than an F&O one, left performance testing out of scope “on the assumption that Microsoft’s Dynamics 365 cloud service should be performant on its own”, which the blueprint review flagged as a risk.

FastTrack: who qualifies, and what it does not do

FastTrack for Dynamics 365 is a customer success programme run by Microsoft’s Dynamics 365 product engineering team, with Success by Design as its delivery framework. Its eligibility page, dated 29 July 2026, says eligible customers get services that “include solution blueprint reviews and go-live readiness reviews”. For an F&O project the customer has to meet two conditions, and the second has two parts:

• Spend. Customers must “Meet a minimum annual spend across their Dynamics 365 licenses in new deployments of eligible Dynamics 365 applications.”
• A qualified partner. “A Solutions Partner for Business Applications with at least two eligible customer deployments”, where “Finance and operations deployments are required for projects with finance and operations apps.” Listed under the same partner qualification: “Success by Design training and knowledge check completed before the project starts.”

Notice what the spend condition leaves out: the number. Microsoft did once publish one. Its November 2020 announcement set “a lowered minimum annual Dynamics 365 investment of $100,000”, with the full programme kept for customers investing $300,000 or more a year. The current page repeats neither figure, and its only advice is “For more details, reach out to your partner or Microsoft account team.” Treat any threshold quoted in a sales conversation as unconfirmed, and get the eligibility answer from Microsoft in writing before the plan depends on it.

Projects that do not qualify are not left with nothing. Microsoft’s self-guided resources “include on-demand Success by Design training, product TechTalks, and a go-live readiness assessment for select Dynamics 365 applications.”

It also matters what FastTrack is not. Microsoft’s FastTrack overview is direct that its architects have “no formal role on the project and we don’t design or develop a solution for the customer.” Your partner designs and builds the solution, and you own it. In our view, a resourcing plan that counts the FastTrack architect as design capacity is one architect short. FastTrack’s architects run workshops at key project stages and review the blueprint and go-live readiness; they do not write the solution design, configure legal entities or own the integration specifications.

Where an F&O implementation lives now

This is the change a plan written before 2026 will not reflect. Microsoft’s Lifecycle Services project creation freeze took effect this year:

“Starting February 16, 2026, you can’t create new cloud implementation projects in Microsoft Dynamics Lifecycle Services for Dynamics 365 Finance, Dynamics 365 Supply Chain Management, and Dynamics 365 Project Operations. New customers for these products should use the Microsoft Power Platform admin center for environment and project management.”

The freeze does not touch existing customers with active Lifecycle Services projects, Dynamics 365 Commerce projects, on-premises implementations, tenant-to-tenant migrations or AX 2012 upgrade projects. There is an exception form for a business-critical need, and “Approval isn’t guaranteed.” An estate still on AX 2012 keeps its Lifecycle Services upgrade route; what staying on AX now exposes you to is covered separately.

For a new F&O implementation, much of the familiar delivery tooling has moved or gone. Microsoft’s unified admin overview and its guidance for partners and systems implementers set out the differences:

Two rows change the shape of the project. Environment planning becomes capacity planning, checked before each new environment rather than counted in purchased slots. And release management becomes a pipeline, because production can be deployed by automation rather than through a portal.

One status label is worth checking as well. Microsoft’s unified environment types page, dated 23 July 2026, lists the ERP templates for a new environment as “Finance (preview)”, “Supply Chain Management (preview)” and “Project Operations Integrated (preview)”. The page does not say what that label means for a production workload, so ask your Microsoft account team before the plan assumes it means nothing.

There is a trap in the documentation too. Several Microsoft pages still describe the Lifecycle Services process as the default, including the service description and the environment planning guidance, while the go-live guidance says it covers projects “in Lifecycle Services if you already have a project there”. When a Microsoft page and the freeze page disagree, read the date on both. When a partner’s plan for a new customer mentions a Lifecycle Services project, ask whether an exception has been granted, because otherwise it cannot be created.

Existing customers have a path across. A self-service migration entered public preview in September 2026. It works one environment at a time, “Migration is a one-way operation”, and during the preview Microsoft recommends migrating sandboxes first and not using it for production. Plan for about 15 minutes of downtime per application server instance. Cloud-hosted developer environments cannot be migrated; Microsoft’s advice is to deploy unified developer environments in their place, or use a downloadable VHD.

The environment plan is the delivery plan

Microsoft’s environment planning guidance asks for the environments plan early, and says what it is for: once it is final, “you can define the flows for building and moving the code and the data across environments.” The list of environments is the skeleton of the delivery plan. Read across Microsoft’s guidance, the environment list for an F&O implementation looks like this, whichever admin center it runs in:

• Development, one per developer. In the admin center that is a unified developer environment, “Intended for single-developer use” and not suitable for performance testing.
• A golden configuration environment, which Microsoft recommends for F&O with a strict rule: “You don’t create any transactions or test data in this environment.”
• Data migration, on “a dedicated high-tier data migration environment that’s sized appropriately to handle the volume of data in scope”, because migration “shouldn’t coexist with other testing activities.”
• System integration and acceptance testing on a Tier 2 or higher environment in Lifecycle Services, or a unified sandbox in the admin center. A Tier 1 environment “isn’t suitable for UAT or performance testing.”
• Performance testing, in what Microsoft’s test guidance calls “a dedicated performance testing environment”, sized for your transaction volumes.
• After go-live, a support environment. Microsoft’s advice is that “if you plan to work on new releases, get an additional Tier-2 or higher environment to support production.”

What each costs is in the cost article. The delivery point is that a plan with fewer environments than isolated workstreams has migration and testing queuing for the same sandbox, the combination Microsoft says not to run together. And production is not somewhere you build: “Use the production environment to operate the solution, not build it.”

Data migration with the data management framework

The data management framework is the primary data tool in finance and operations. Microsoft’s data management overview describes it as a set of data entities, projects, jobs and packages serving three scenarios: data migration, setting up and copying configuration, and integration. Extraction and transformation upstream can use whatever suits the source, from Azure Data Factory to SQL Server Integration Services; inside F&O, the framework works through data entities.

Three of its mechanics shape the delivery plan.

Sequencing is the design. Entities load in a defined order within a package, and packages in a defined order across modules, because, as Microsoft puts it, “Dependencies exist within and across modules.” Sales tax codes must exist before sales tax groups, vendors before purchase orders. Getting that order right is design work for Implement, not for the week before cutover.

Partial loads are allowed, and that cuts both ways. If an import fails, you can “skip selected records and choose to proceed with the import by using only the good data”, then fix and reload the rest later. That keeps a rehearsal moving. It also means every run produces an error list, and an error list with no named owner is how bad records reach cutover weekend.

Configuration and migration data are separate streams. Microsoft’s guidance on configuration and migration data keeps configuration data such as currencies, tax codes and parameters in the golden configuration environment, and treats migration data as master data plus open transactions: open orders, stock on hand and balances. It names three roles for the work: a data migration analyst, a data steward and a data migration architect or developer.

Microsoft’s minimum for rehearsal is modest: “test and verify your data migration at least once in your system integration testing (SIT) and user acceptance testing (UAT) environments.” Its go-live prerequisites raise the stakes: “Use migrated data for testing. This data should include master data and opening balances, even if they aren’t yet final.” So the migration workstream has to deliver loadable data before acceptance testing starts, and a late migration delays testing rather than running alongside it.

In our F&O delivery and rescue records, the point where projects slip most often is entry into user acceptance testing, at the move from Implement to Prepare, and the cause is almost always unreconciled migrated data and dual-write or integration payloads arriving late, rather than defects in X++ code or configuration. Conference room pilots and system integration testing are signed off on clean, hand-built master data in a sandbox. Then the first full legacy load lands two weeks before UAT, and broken chart of accounts mappings, unvalidated open-order balances and number sequence collisions fail the standard order-to-cash and procure-to-pay scripts on day one. A planned four-week business validation window turns into an emergency data cleanse.

Our rule follows from it: we never let an F&O project declare UAT readiness until at least two full-volume data migration rehearsals have completed cleanly, with the data loaded into the UAT sandbox, built from the golden configuration, and reconciled by the finance and supply chain process owners before the first UAT script runs. These two pre-UAT rehearsals are the first two of the three or four full rehearsal runs budgeted across the project, with the final one or two runs serving as the full dress-rehearsal mock cutovers in Prepare.

At cutover the route depends on where the project lives. In Lifecycle Services, Microsoft’s guidance is to prepare and validate data in a non-production environment and copy the sandbox database to production. In the admin center, “code is always copied with data”, and production can be created by converting a validated sandbox. Decide the route in the cutover plan, and rehearse the one you will use.

Testing, and the end of RSAT

Microsoft’s regression testing guidance starts from a point worth putting in front of any steering committee: “Microsoft does regression testing, but the data composition, specific customer configurations, and unique extensions mean customers must perform their own regression testing in their own environment.”

Microsoft’s RSAT documentation sets out which tool belongs to which layer of testing:

• Unit tests use the SysTest framework, not RSAT.
• Component tests use the Acceptance test library of X++ test helpers.
• Data integration tests use the data management framework and its Data task automation.
• Business cycle tests, the end-to-end scenarios users accept, are what RSAT was built for, turning Task recorder recordings into automated tests run through Azure DevOps.

Performance testing sits across all of them, and Microsoft’s test types guidance calls it “one of the most dominant risk factors in implementation projects, because it’s often overlooked or underestimated”, and says: “Don’t delay performance testing until the end of the implementation.” It is the risk Microsoft’s blueprint review example caught.

Now the change. The same RSAT page opens with a notice: “The Regression Suite Automation Tool (RSAT) is marked for deprecation and won’t be supported after May 15, 2027.” Microsoft’s list of removed and deprecated features answers the obvious next question, whether it is replaced by another feature, with “No”. The same entry gives the deployment option as “On-premises”, but the notice on the RSAT page itself, and in Microsoft’s regression tooling guidance, carries no such limit.

Microsoft’s documentation has not fully caught up with itself. Its service update availability page, updated on 8 October 2026, still says “We recommend that you use tools such as the Regression suite automation tool (RSAT) for regression testing.” Its regression tooling guidance lists RSAT, Playwright, Selenium, EasyRepro and several third-party products, and says “Microsoft doesn’t recommend one tool over another.”

For an F&O implementation going live in the next year, that makes the regression tool a design decision. The regression suite is a deliverable of the Implement phase, and it is what makes every update after go-live survivable. A suite built on RSAT today rests on a tool whose support ends in May 2027, two months after version 10.0.51 is targeted for general availability. The testing strategy Implementation Review is the place to choose its successor, before the first test case is written.

In our view, do not build a new regression pack on RSAT for anything that must run after 15 May 2027. A typical full implementation starting now runs the twelve to eighteen months set out in our cost article, so it goes live after RSAT support has ended, and a suite recorded on RSAT today is rework before it has tested a single update in production. On our own projects we separate the two layers: SysTest for X++ business logic, which the deprecation does not touch, and for browser regression either a code-owned Playwright suite kept in the client’s own repository or the enterprise Dynamics 365 test platform the client already licenses.

Go-live readiness: what the review checks

For projects in Lifecycle Services, Microsoft’s go-live guidance is specific. The review takes place “No later than four weeks before the go-live”, and production is deployed only after it completes. Before the review can start, the prerequisites include:

• acceptance and performance testing complete or almost complete on a Tier 2 or higher environment, with test cases covering the entire scope;
• testing on migrated data, including master data and opening balances;
• testing with the correct security roles, default and custom;
• the solution meeting company and industry regulatory requirements, with customer approval;
• every licence needed for go-live bought in the correct tenant;
• the Customization Analysis Report run and its critical issues addressed;
• a go-live date that is “the date when end users start live operations, not cutover activities.”

There are two ways through the review. Unless the project opts out, an AI review runs, and it “completes on the same day”; the manual route takes “up to three business days for the initial report” plus any mitigation. Production deployment then takes about 30 minutes.

For projects managed in the Power Platform admin center, it is less clear. The same page says its steps do not apply to implementations managed in the admin center, which creates production by provisioning it or by converting a sandbox, during which the environment is inaccessible for up to two hours. Microsoft’s documentation, as checked on 26 October 2026, does not describe how the review gates production for an admin center project. Its Implementation Portal guidance, dated July 2023, still says “All finance and operations apps implementation projects must complete a go-live readiness review with Microsoft before the production environment can be deployed”, but the release step it describes is Microsoft switching on the production slot in Lifecycle Services. Success by Design still calls the review mandatory, and FastTrack still lists it among its services.

In our view, hold it anyway, four weeks out, whether or not anything in the tooling enforces it, and write it into the contract as a go/no-go gate. Microsoft’s tutorial for converting a sandbox to production does not mention the Go-live Readiness Review, so in the admin center nothing in that process enforces it. Its prerequisites are a go-live checklist in their own right, and the Prepare phase work Success by Design expects alongside it does not depend on the admin center at all: a cutover plan with go/no-go criteria, scheduled mock go-lives, a support model that is ready, and a deployment runbook “with tasks, owners, durations, and dependencies defined.”

After go-live: an update cycle that does not stop

An F&O implementation does not end at go-live, because the platform keeps moving underneath it. Microsoft’s One Version service updates FAQ sets the rules:

• Service updates ship four times a year, in February, April, July and October. You must take at least two a year, you can pause only one at a time, and “You’re required to use an update that’s no more than one update behind the current update.”
• April and October are the major updates. Breaking changes are introduced only in those, and are “communicated 12 months in advance”.
• Validation time is short. With autoupdate, “You have seven calendar days to do testing and validation before the production environment is updated.”

The calendar is already running. Version 10.0.50 entered preview on 23 October 2026 and is targeted for general availability on 22 December 2026, with the first production autoupdate window from 31 January 2027.

Underneath the service updates sit proactive quality updates. Since version 10.0.47 they arrive every two weeks, production receives each one at least five days after the sandbox, and on whether customers can delay, reschedule or pause one, Microsoft’s answer is “No.”

Microsoft’s service description puts the consequence on the customer’s side of the line: “Manage application updates and validate extensions”. So the operating model after go-live needs three things the project should hand over: a sandbox kept current for validation, a regression suite that can run inside a five to seven day window, and a named owner accountable for each update, including when to pause a service update.

Hypercare does not settle that on its own. Where hypercare is extended to sixty or ninety days, it masks structural decay rather than preventing it, which is why our own F&O build hypercare is capped at 30 days, with the ongoing operating model settled before cutover. The update calendar does not wait for hypercare to end.

In our view, the operating model has to be settled before anyone buys support for it. A managed service bought before the operating model is settled becomes the destination for unresolved internal politics, contradictory change requests and unowned business logic, and it guarantees a failed service review around month six, with the provider holding it. How to make that decision is the subject of managed service versus project delivery.

Where to start

Before signing off an F&O implementation plan, check seven things.

1. Which admin center the plan assumes. For a new customer since 16 February 2026, that is the Power Platform admin center, unless an exception has been granted. Check that your Azure region supports finance and operations production and sandbox environments, and ask Microsoft in writing what the “(preview)” label on the Finance, Supply Chain Management and Project Operations templates means for your production environment.
2. When the Solution Blueprint Review starts. In Discover, before design decisions are taken, not after.
3. FastTrack eligibility, in writing. Microsoft no longer publishes the spend threshold, so get the answer from Microsoft before the plan relies on it.
4. The environment list against the workstreams. Golden configuration, data migration, testing and performance each need room of their own.
5. Data migration as a gate into UAT. At least two full-volume migration rehearsals, reconciled by finance and supply chain owners, before UAT begins. Troubled F&O plans we review typically show data migration as a single bar running alongside UAT instead.
6. The regression tool. Not RSAT for anything that must run after 15 May 2027.
7. The owner of the update cycle after go-live, named before go-live rather than discovered after it.

Veratas implements Dynamics 365 finance and operations, from fit-gap through go-live and the update cycle after it. The same decide-early logic applies on the customer engagement side, set out in our Dynamics 365 Customer Service implementation article. If you are planning an F&O implementation, or have one whose plan was written before February, talk to our team.

Frequently asked questions

Is Success by Design mandatory for an F&O implementation? Microsoft recommends the framework for all Dynamics 365 implementation projects, and within it describes two reviews as mandatory: the Solution Blueprint Review, which begins in the Discover phase, and the Go-live Readiness Review before production. It works alongside your partner’s own delivery method rather than replacing it.

Does Microsoft publish the FastTrack minimum spend? Not any more. The current eligibility page requires a minimum annual spend on Dynamics 365 licences in new deployments of eligible applications, but gives no figure and refers customers to their partner or Microsoft account team. The $100,000 minimum Microsoft announced in November 2020 is not repeated there. The partner must be a Solutions Partner for Business Applications with at least two eligible finance and operations deployments, and the partner qualification also lists Success by Design training and a knowledge check, completed before the project starts.

Can a new customer still use Lifecycle Services? Not for a new cloud implementation of Finance, Supply Chain Management or Project Operations. Since 16 February 2026, new customers manage environments and projects in the Power Platform admin center. Existing Lifecycle Services projects, Commerce, on-premises implementations, tenant-to-tenant migrations and AX 2012 upgrades are unaffected, and there is an exception process with no guarantee of approval.

Is RSAT still supported? Until 15 May 2027. Microsoft has marked the Regression Suite Automation Tool for deprecation and names no replacement feature. Its regression testing guidance lists Microsoft and third-party alternatives without recommending one, so the choice of tool belongs in the project’s testing strategy.

Can we pause updates after go-live? Service updates, yes, but only one at a time: Microsoft releases four a year, requires at least two, and requires you to stay no more than one update behind. Proactive quality updates, no: they arrive every two weeks, reach production at least five days after the sandbox, and cannot be delayed, rescheduled or paused.

Anuj Kumar Mishra

Operations head with 20 years of experience delivering business intelligence, ERP and AI programmes across healthcare, finance and manufacturing. Focus areas include Power Platform adoption and governance, delivery models, and managed services.