Dynamics 365 in the UAE: Which Product You Are Actually Buying

"We are looking at Dynamics" sounds like a shortlist and is not one.

Dynamics 365 is a brand over several products that share a name and very little else. Two of them are full ERP systems descended from different acquisitions, written on different codebases, sold at different prices and delivered by different people. Four more are separately licensed applications that buyers routinely describe as modules. And behind all of them in this market sits a large installed base still running the products Microsoft bought in the first place, each with its own exit and its own date.

Establish four things before anyone demonstrates anything: which product is being proposed, whether its UAE localisation is Microsoft's or the partner's, who maintains that localisation, and what happens to it at the next release wave. A proposal that cannot answer those in writing is not yet a proposal about a product.

That is the whole answer. The rest of this article is what each product in the family actually is, what the legacy estates in this market have to do and by when, and the places where the numbers a partner quotes are not the numbers on Microsoft's own pages.

The family, and why its members are not related

Microsoft did not build Dynamics 365 in one place. It assembled it, largely by acquisition, and put one name on the front some years later. The name is a marketing artefact. The products underneath it are not.

Dynamics 365 Business Central is the mid-market ERP, descended from Navision — sold in this region for a long time under that name and later as NAV. It covers finance, purchasing, inventory, warehouse, light manufacturing, projects and service, and it suits companies that want one system to run the operation without a large internal IT function.

Dynamics 365 Finance and Operations descends from Axapta, which Microsoft renamed Dynamics AX. It is a different codebase built for a different size of company: multi-entity groups with real complexity in manufacturing, distribution or regulated reporting. It is sold as a set of applications — Finance, Supply Chain Management and their siblings — rather than as one product at one price.

These are not two editions of one thing. They share no data model, no extension model, no development tooling and no implementation method. A partner who has delivered one has not, by that fact, delivered the other, and a reference site for one tells you very little about delivery on the other. Ask which product every named person on the proposed team has actually implemented, and how recently. Where each of these sits against everything else sold into this market is worth settling first, because the band you are in decides which half of the family is even relevant to you.

The practical consequence of the shared brand is that a company can receive two Dynamics proposals in the same fortnight, from two firms, which look like two prices for the same system and are nothing of the kind. Reading them side by side without establishing which product each describes is the commonest way a Microsoft evaluation goes wrong here, and it happens before anyone has looked at a single requirement.

What the two products cost on Microsoft's own pages

Microsoft publishes list prices for both, which is more than most ERP vendors do, and reading the pages yourself takes about four minutes. Business Central Essentials is listed at USD 80.00 per user per month paid yearly, Premium at USD 110.00, and a Team Members licence at USD 8.00. Team Members is the class of licence for people who approve, view and enter time without running a process, and for a company with a long approval tail it is the most consequential line on the page.

The Business Central pricing page carrying those figures also carries a footnote worth reading rather than skipping: "Prices shown are for informational purposes only and may not be reflective of actual list price due to currency, country, and regional variant factors. Your actual price will be reflected at checkout."

So the published figure is a starting position, not your price. What it is good for is the shape of the decision rather than the total. It tells you what a tier move costs across your whole user population, which is the calculation most quotations bury, and it lets you model your own role design before a partner models it for you. The answer to "which tier" is a decision about how your people work, and it is far cheaper to take before somebody has designed around a licence you never chose.

The other half of the family is published in the same place and the same form. The Dynamics 365 Finance pricing page lists Finance at USD 210.00 per user per month paid yearly and Finance Premium at USD 300.00, under the same footnote. Supply Chain Management and the other Finance and Operations applications are licensed separately again.

Set the two pages next to each other and the gap between them is not a discount negotiation. It is a different product for a different company, and the licence difference is the smaller half of it: implementation, data migration, testing and internal effort all scale with the same complexity the price is signalling. A company that lands on the more expensive product because a partner's practice happens to be stronger there has bought an implementation shape as well as a licence, and the shape is what it lives with for a decade.

Which of the two your business needs is settled by requirements you can name — entity count, manufacturing depth, statutory reporting, how much of your process is genuinely unusual — rather than by ambition or by turnover. The requirement-by-requirement fork between the two is the single decision inside this family that moves a project's cost by an order of magnitude, and most buyers do not know the fork exists until a licence quote arrives.

Sales, Field Service and HR are purchases, not modules

Both ERP products cover finance and operations. Neither covers the customer-facing and people-facing ground that buyers assume the word "Dynamics" includes.

Customer relationship management is Dynamics 365 Sales. Case handling and service desks are Dynamics 365 Customer Service. Scheduling engineers to site is Dynamics 365 Field Service. Employee records are Dynamics 365 Human Resources. Each is a separately licensed application with its own price, its own renewal, its own configuration and its own integration to whichever ERP you bought.

That is not a defect and it should not be argued as one. Each of those applications is deeper than the equivalent folded into a single-suite product. But it changes the count. What a board heard as "we are putting in Dynamics" is a set of contracts with several renewal dates, and every boundary between two of them is a place where the same customer or the same employee exists twice, under two definitions of what "active" means.

So ask which applications are inside the quoted figure and which are named in the scope but not in the price. Ask it in writing, and ask for the answer as a table rather than a paragraph. The gap between those two lists is where a Microsoft programme's budget tends to go in year two, and the reason is structural rather than commercial: each additional integration makes the estate harder rather than easier, and a family sold as separate applications generates more of them than a suite does.

The minimum seat count that is not on Microsoft's page

Ask around this market about Finance and Operations and a number comes back with striking consistency: a minimum seat count, described as Microsoft's rule, below which the product will not be sold to you. Different partners quote different floors. Each is presented as a fact about the vendor.

The Dynamics 365 Finance pricing page states no minimum seat count and no minimum purchase. The Business Central pricing page states no minimum seat count either. Both pages are public, both are Microsoft's own, and neither contains the floor.

That does not make the number a lie, and it is worth being precise about what it might be instead. It could be the partner's own commercial minimum, below which the engagement is not worth their while to run properly — an honest position, and one we would defend. It could be a term of a specific agreement. It could be a rule of thumb about which companies the product suits, dressed as a rule about licensing. What it should not be is presented as the vendor's rule when the vendor's page does not say so.

So put the question back, in writing: is this Microsoft's minimum or yours, and where is it published? Apply the same test to every other figure in the quotation, because a number nobody will source is a number that moves. What actually moves a Business Central figure in this market, line by line, is the difference between a budget and a hope.

The answer to the seat question also tells you how that firm will handle the next thing you cannot verify for yourself, which over a five-year relationship is worth more than the discount you were arguing about.

GP, NAV and AX: three estates, three exits, three deadlines

The Gulf has a Microsoft installed base considerably older than the Dynamics 365 brand. Trading houses, contractors and manufacturers here bought Great Plains, Navision or Axapta in the 2000s, customised them heavily, and have been running them ever since with a small internal team and a partner who has changed hands twice.

All three are on-premises, and every exit on offer moves you to a subscription product hosted by Microsoft. That is a hosting decision as well as a product decision, and it lands on procurement, security review and the cost model at the same time. The honest version of the cloud and on-premises argument here is worth having separately from the product argument, because the two get conflated in every proposal and only one of them is really about software.

Beyond that shared move, each of the three has a different exit and a different date. Treating them as one problem — "we need to get off the old system" — produces a plan that is wrong for at least two of them, and usually wrong in the direction of underestimating the oldest.

Dynamics GP

GP is the estate where the published position is clearest, and where the version you are on changes the deadline by years rather than months. Microsoft moved GP to its Modern Lifecycle Policy in October 2019, and the supported version line is 18.x. Everything before that line sits on the older Fixed Lifecycle table instead. So the first thing to establish, before any discussion about replacement, is which of the two you are actually on — and a surprising number of finance directors do not know.

Microsoft's Dynamics GP lifecycle page carries the Fixed Lifecycle table, and that table has been emptying. GP 2013 and 2013 R2 left mainstream support on 4 April 2018 and extended support on 11 April 2023. GP 2015 and 2015 R2 left mainstream on 14 April 2020 and extended on 8 April 2025. GP 2016 and 2016 R2 left mainstream on 13 July 2021 and extended on 14 July 2026 — a date that has already passed. GP 2018 and 2018 R2 left mainstream on 10 January 2023 and run to 11 January 2028.

That last row carries a sentence which is easy to miss and which decides the plan: "There are no tax releases or hotfixes available for Dynamics GP 2018 or Dynamics GP 2018 R2 that would allow you to stay on the fixed lifecycle." A date in a support table is not a commitment that anything is being shipped against it, and a finance system receiving no tax releases is already out of support in the only sense that matters to a return.

For anyone on 18.x the horizon is stated on the same page: "we will end Dynamics GP support on December 31, 2029 (previously announced end date was September 30, 2029), for product enhancements, regulatory (tax) updates, and technical support. Security updates/patches, if needed, will be made available until April 30, 2031."

Read those as two dates for two different things. The first is when regulatory and tax updates stop; the second is when security patches stop. A UAE finance department cares most about the first, because the day a system stops receiving regulatory updates is the day it stops being usable for statutory reporting, whatever it is still doing operationally the morning after. Working out what the GP dates mean for a UAE finance department, and the order to do things in, is a separate exercise from choosing a replacement, and it carries the earlier deadline of the two.

Until then, GP on the Modern Lifecycle receives three all-inclusive updates a year, in June, October and December. That is a cadence you can plan a migration around rather than one that surprises you, and it is the practical reason a GP exit is usually the least disruptive of the three: the system you are leaving keeps working properly while you leave it, which is not true of the other two.

Dynamics NAV, and Business Central's own early versions

This estate has the most surprising arithmetic in the family, and Microsoft publishes it rather than leaving it to be discovered mid-project.

A NAV 2015 (version 8), NAV 2016 (version 9), NAV 2017 (version 10) or NAV 2018 (version 11) system — and Business Central October 2018 (version 13) alongside them — reaches Business Central 2026 release wave 1 only by hopping through version 14, then version 25, then version 28. Three technical upgrades, not one, before the system is on a release Microsoft is currently shipping.

That comes from Microsoft's own Business Central upgrade-path documentation, which adds the line that decides the budget: "This path requires you convert your application from C/AL to AL." Every customisation your business has accumulated since Navision went in is written in the old language and has to be rewritten in the new one. For an estate customised over fifteen years, that is not a task inside a migration plan. It is the plan.

The shortcut that used to exist has closed, and the same page says so plainly: "Starting in 2025 release wave 1 (v26), the direct upgrade from Business Central 2019 (v14) to the latest release won't be supported. The supported upgrade path will be through 2024 release wave 2 (v25)."

Nor is the stepping stone somewhere to stand. Microsoft notes that "mainstream support for version 14 ends in October 2023, and minor updates to the version are no longer available. New customers can't use version 14 in production, but only as a path for upgrading to latest version." The route to a supported system runs through a version that is itself unsupported and exists only as a route.

What to take from that is a sequencing point rather than a technical one. A NAV move scoped as an upgrade will be quoted as an upgrade, and will then meet the rewrite around the middle, at which point the conversation about money happens with your old system already half dismantled. What a NAV estate actually has to do to reach a supported Business Central is the question to settle before anybody prices anything.

Dynamics AX

AX estates exit to Finance and Operations, and this is the one route in the family that nobody sensible calls an upgrade. It is a reimplementation with a data migration attached, on the product at the top of the price range above, and it should be planned and funded as a new system rather than as a version change.

We are not going to give you lifecycle dates for AX here. The ones we could give you would come from memory rather than from a page read this week, and a support date you are going to act on ought to come from Microsoft's own lifecycle documentation on the day you read it. Ask your partner to put the current lifecycle position of your specific AX version into the proposal, with the link. A partner who cannot produce that inside an afternoon is not the partner for a migration of this size.

Localisation: the question is who maintains it

Microsoft ships country localisations for a defined list of markets, and describes the boundary between core and local functionality in its own Business Central localisation documentation. That boundary is not a technical curiosity. It is where responsibility changes hands, and it is the most useful page in a UAE evaluation of this product.

For a buyer here the question is never whether a localisation exists. It is which side of that line your requirements fall on, and who owns the side they land on. A Microsoft-maintained country version and a partner-built app sitting on the worldwide base look identical in a demonstration and behave entirely differently three years later, when the app's publisher has been acquired, or has left the region, or has simply not certified against the current release.

So the questions are these, and they belong in an email rather than a meeting. Which of the two am I being sold. Who publishes it. How quickly is it certified against each release wave. What is the support commitment, in writing, and for how long. And what happens to my VAT return if that publisher stops publishing. Almost nobody asks them, and they are the cheapest risk reduction available anywhere in the evaluation.

Where the UAE gaps usually are on Business Central, and what fills them matters more than any feature list, because the gap is rarely in the tax calculation. It is in the document, the archive, the Arabic on a printed invoice, and the structured e-invoicing fields that somebody has to populate before an invoice can be issued at all.

The release wave, and what it does to a customised estate

Microsoft names its releases by wave — its own upgrade documentation refers to 2024 release wave 2 as version 25 and to 2025 release wave 1 as version 26 — and on the online products those waves arrive whether or not your estate is ready for them.

For most companies that is a relief rather than a threat. The base product moves and nothing breaks, because extensions attach to a published surface Microsoft has committed to keeping stable. This is the structural advantage of the platform and it is real.

The failure mode is not the base product. It is the app in the middle: a localisation app, an industry app, a marketplace app bought for one requirement in year one, whose publisher has not certified against the incoming wave. One uncertified dependency freezes an estate as effectively as a codebase nobody can afford to upgrade, and the company that ends up frozen almost never chose badly. It chose a good app from a publisher whose commercial priorities later changed.

The defence is unglamorous and it is the whole answer: an inventory of every extension in the estate, kept current, with its publisher, its certification status and a named person who checks it before each wave. Nobody sells that. Somebody inside your company has to own it, and the time to name them is before go-live rather than after the first wave that breaks something.

The arithmetic of when an upgrade is worth doing and when it is not reads differently on a product where the timing is not yours. Here the question is not whether to move, but whether you will be ready when it moves, and that is decided by choices taken in year one about how many third-party dependencies you accepted in exchange for a shorter implementation.

Five questions, in writing, before anybody demonstrates anything

Which product is this? Business Central or Finance and Operations, named in the proposal, with the licence lines that belong to it and the list price each line is discounted from.

Whose localisation am I buying? Microsoft's country version or a partner app on the worldwide base. If it is a partner app, who publishes it and what is the certification commitment per wave.

What is inside the price, and what is named in the scope but not priced? Two lists, side by side. Sales, Customer Service, Field Service and Human Resources belong on one of them, explicitly.

What happens at the next release wave? Who checks that every extension is certified, when they check it, and at whose cost the remediation happens if one is not.

What happens on the day we stop paying you? Where the data goes, who holds the source of any partner-built extension, and what a successor firm would need in order to pick the system up.

The first four are specific to this family. The last separates suppliers on any platform, and it belongs alongside the questions that separate the products from the salespeople in any demonstration, whoever happens to be running it.

Where this leaves you

Business Central is the answer for a great many UAE mid-market companies, particularly the ones already standardised on Microsoft, that want a system which stays current without a funded project every few years. Finance and Operations is the answer for a genuinely large and genuinely complex group, and it is proposed to companies that are neither rather more often than it should be. GP, NAV and AX are not answers any more. They are estates with dates attached, and the date is the reason to move rather than anything wrong with the software itself — a distinction worth making out loud, because a team that liked its old system resents being told it was bad and accepts being told it is unsupported.

None of that is your decision though, because the decision is which product against which alternative, and for most companies in this band the real comparison is not inside the Microsoft family at all. An Odoo partner's comparison of Odoo and Business Central, including the profiles where we would tell you to buy the Microsoft product, is written to be usable by somebody who has no intention of hiring us.

What you should not do is settle any of it on the strength of a demonstration. A demonstration shows a configured product with clean data, driven by a person who has driven it four hundred times, and it is equally impressive on every product in this family and on every competitor to it. It cannot tell you which requirements are standard, which are gaps, what each gap costs, and what is being quietly excluded. Those four lists are the entire content of a proposal worth signing, and none of them can be produced from a meeting room. They are produced by somebody working through your own transactions, in your own data, with the awkward ones included rather than set aside for later. Getting them requires a written diagnosis of your own processes before anybody quotes against them, which is what we do when we scope an ERP implementation, and we will do it against a Microsoft proposal as readily as against our own.

We are an Odoo partner. That is a commercial interest and you should read this page with it in mind. It is also why this article carries no opinion about which Dynamics product is better for you: the question cannot be answered without your requirements in front of it, and anybody offering the answer before they have seen them is selling a practice rather than assessing a business. The four things at the top of this page are the ones a buyer here can establish without help, in writing, before spending a single afternoon in a demonstration, and doing that much alone changes what the rest of the process costs you. It also changes who you are dealing with, because a firm that answers those four straight and in writing has told you more about how the next three years will go than any reference call will. How the selection ought to be run is published in full rather than described in a meeting, which means you can run it with somebody else, or run it yourself.