Twelve kinds of Dynamics 365 project. Which one are you in?

You have no ERP worth converting. You run on spreadsheets, a desktop ledger, or a system you have outgrown and do not want to copy. Your masters can be cleaned, and you can start from opening balances and open documents. Old transactions do not need to post again.

Implement Dynamics 365 Finance and Supply Chain, or Business Central, on standard processes, and take it through the first close.

• Configure first, extend second, and customise last.
• Load masters, opening balances, and open documents, and reconcile them to the source.
• Prove security, workflow, and the statutory close before go-live.

You are live on Dynamics AX 2012 and want Finance and Operations without redesigning how you work. Your configuration and your history need to come across. Some customisations still match the way you operate. A move from SAP, Sage, Oracle, NAV, or GP is a migration, not this path.

Upgrade AX 2012 to Dynamics 365 Finance and Operations on the Microsoft upgrade path: code, configuration, and data.

• Keep the customisations that still earn their place, and retire what Dynamics 365 now does as standard.
• Bring configuration and history across, and tie the balances back to AX.
• Retest the add-ons and integrations you rely on.

The way you operate is mostly right, and the data is not: duplicates, closed companies, and years of corrections. You want familiar structures without importing the mess. You do not need the full history in the new system.

Implement Dynamics 365 on the agreed design, and load masters, opening balances, and open documents only.

• Write down what is reused and what is redesigned before build starts.
• Cleanse masters before they are loaded. Do not migrate a record you would not enter by hand.
• Reconcile the opening trial balance to the source.

One company, country, or site is already live on Dynamics 365. The next should follow that design, with local tax and statutory rules made explicit. Local teams are asking for exceptions before they have used what is already live.

Deploy the existing solution to a new legal entity or site without redesigning the core.

• Reuse the chart, processes, security, and integrations.
• Localise only where the law, or a real operating difference, requires it.
• Migrate that entity's masters and open position, and train people on the template.

You are live, and the intensive support after go-live is ending. You do not have a team that can run the close, the batch jobs, and the vendor updates alone. The same incidents return each month. Nobody owns the calendar of Microsoft updates.

Operate the live Dynamics 365 system so the business closes on time and the platform stays on a supported release.

• Name an owner for incidents, the month-end, and the update schedule.
• Fix recurring issues at the cause, rather than answering them again each month.
• Keep a separate path for any change that is not a break-fix.

You are already on Dynamics 365, but Finance and Operations updates have been paused, or Business Central is more than one wave behind. A feature, a tax change, or an add-on now requires a newer version. What fails in testing is changed Microsoft behaviour, not a new way of working.

Bring the environment to a supported release and prove that the current processes still complete.

• Apply the update in a non-production environment first.
• Regression-test order to cash, procure to pay, the close, tax, and integrations.
• Confirm customisations and ISVs on the new version, or retire them.

Your source system is SAP, Oracle, Sage, something built for you, AX 2009, NAV, or GP. It does not share a database with Dynamics 365, and there is no upgrade path that carries it into Finance and Operations. History, the chart, and the documents do not map one for one.

Design the Dynamics 365 processes, then move masters and the open position from the source, reconciled.

• Write the map: what moves, what is transformed, and what stays behind.
• Reconcile trial loads to the source before the dress rehearsal.
• Rebuild integrations against Dynamics 365. Do not point them at the old database.

The core process already works. What you need is a feature, a report, a localisation, or a spreadsheet you want inside the product: a price rule, a label, a statutory return, a workspace. It has an owner and a test, and it does not reopen the whole design.

Deliver one agreed capability on the live system, configured first and extended only where the product stops.

• Write the change: what is in, what is out, and what it will cost at the next update.
• Try standard configuration before any extension.
• Test the change against the close and the processes it touches.

Your teams re-key orders, payments, stock, or employees. A bank, a payroll engine, an e-invoicing authority, a store, a warehouse, or another business system sits outside Dynamics 365. Files fail quietly and are corrected by hand.

Move one business document from the system that owns it to the system that must account for it, with a visible failure path.

• Name the source of truth for each field before anything is built.
• Agree the message, the schedule, the retry, and who owns a rejected row.
• Reconcile counts and values. Do not stop at "the file was sent".

A sale, a split, or a regulation requires one company, division, or country to stand alone. Two businesses share a legal entity, a chart, or an item list, and can no longer do so. You cannot yet produce clean opening balances for the business that is leaving.

Create a Dynamics 365 legal entity, or a separate environment, that holds only the carved-out business, with an opening position both sides accept.

• Fix the date of the split, and list the masters, open documents, stock, and balances that move.
• Design intercompany between the two sides before the cut.
• Reconcile both trial balances on the morning of the split.

More than one country, brand, or business unit will use Dynamics 365, and they are not all in the first release. Each is asking for its own chart, its own items, and its own process. Headquarters wants one view. Local teams need local statutory compliance.

Design and prove the core once: processes, chart, dimensions, security, and the rules for what a country may change.

• Prove the core on a pilot entity that has run it, not only read it.
• List local tax and statutory needs as extensions, with the cost of each at update time.
• Agree how a country asks for a change to the core, and who may approve it.

AX, NAV, GP, or Business Central still runs on your servers or on a host. The pain is patching, a file share, a local database job, and versions nobody will move. The business process is not the main complaint. How the software is operated is.

Move the estate to Dynamics 365 online, including identity, environments, integrations, and the way updates are taken.

• Design Microsoft Entra ID, the environments, and the production boundary before the move.
• Rebuild integrations for the cloud. Remove maps to a server share or a local SQL job.
• Agree who tests the service update, and on what cycle, so the system does not freeze on the version it landed on.