Dynamics GP End of Support: The Dates, and What They Do Not Mean

A partner has told you that Dynamics GP is dying and that a migration has to start immediately. Some of that is true. The dates are published, they are not in dispute, and you can check every one of them yourself in about five minutes. The rest is a sales calendar wearing the clothes of a deadline, and the two are worth separating before you commit a budget year to the difference.

This page puts the real dates in front of you and then asks what the pitch deck does not: which of them actually binds your company, and what has to be true before a migration is the right use of next year rather than the year after.

Which lifecycle you are on, because it changes every date

Microsoft runs Dynamics GP under two support regimes, and which one applies to you is decided by the version you happen to be running rather than by anything you chose.

The Modern Lifecycle Policy was introduced for Dynamics GP in October 2019, and the current version line under it is 18.x. Under that policy, Microsoft's published lifecycle page for Dynamics GP states: "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." Three all-inclusive updates are released a year, in June, October and December.

Everything older sits under the Fixed Lifecycle Policy, which sets a mainstream date and an extended date per version rather than one date for the product as a whole.

The two groups have opposite problems. A company on the modern line has years and one well-published deadline. A company on a fixed-lifecycle version may have months, or may already have run out, and it will not learn that from a headline saying 2029. If nobody in your finance function can state which of the two you are on without asking IT, that is the first thing to fix, and it is a fifteen-minute job. Where the whole Microsoft mid-market range sits, and why the fork inside it moves a quote by an order of magnitude, is the subject of the guide to the Dynamics 365 family in the UAE.

The published dates

The fixed-lifecycle rows, as Microsoft publishes them:

And on the modern line, the 18.x versions: 31 December 2029 for product enhancements, regulatory (tax) updates and technical support, then 30 April 2031 for security updates and patches if any are needed.

Three of those rows are already behind us. GP 2016 and GP 2016 R2 came out of extended support on 14 July 2026, GP 2015 on 8 April 2025, and GP 2013 on 11 April 2023. If your estate is on one of those lines, the argument about whether to move is over, and the only live question is which quarter and to what.

The two end dates are not the same kind of date

The sentence Microsoft published contains two dates, and a business that reads only the second one has misunderstood its own exposure.

The first, 31 December 2029, ends product enhancements, regulatory (tax) updates and technical support. The second, 30 April 2031, is how long security updates and patches will be made available if they are needed. Sixteen months separate them, and they protect against entirely different things.

Security patches keep a system safe. They do not keep it correct. Nothing in a security patch changes how a tax is calculated, what a return has to contain, or what a compliant document looks like when the rule behind it moves. That is why, for a company filing here, the earlier date is the one that binds. A tax rule can change and the product will not follow it, and you find that out during a filing cycle rather than during a planning meeting.

So the useful ask of whoever supports your system is narrower than "when does support end". Ask which of your jurisdictions' regulatory changes are covered today, by whom, and under what agreement — in writing, because the answer for a UAE entity, a Saudi entity and a group parent may be three different answers and only one may have been thought about. What each obligation demands of a ledger and a set of master data, independent of product, is visible in what an FTA audit turns out to ask for once it arrives. Match that list against the answers you get back. The gap is your real exposure, and it is dated earlier than 2029.

The trap sitting inside the fixed lifecycle

If you are on GP 2018 or GP 2018 R2, the table above says extended support ends 11 January 2028, and reading that row on its own will give you a false sense of room.

The same Microsoft page carries this sentence: "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."

Read it twice. It is the most consequential line on the page and it is not the line anybody quotes. It says the fixed-lifecycle position for that version line is not a place you can sit and remain current. An organisation can therefore hold a perfectly accurate belief that it has until January 2028, and have no route to a compliant tax position for most of that time. The support date and the usable date are not the same date, and only one of them appears in the table.

That is the shape of urgency worth acting on: not "the product is being retired eventually", but "this version has no supported path to staying correct". If that describes you, your timeline is set by your compliance calendar rather than Microsoft's, which usually makes it shorter.

Why a published end date is still not a reason to start this quarter

Now the other half, and it deserves to be written properly rather than as a hedge. The settled position on this site is that the arithmetic decides whether an upgrade is worth doing rather than the vendor's calendar, and the publication of a date does not change that. It supplies one term in the sum.

Today is September 2026. The date that ends enhancements, tax updates and technical support on the current line is more than three years out, and security updates run more than four. A partner presenting that as an emergency is presenting a fact and a conclusion in the same breath, and only the fact came from Microsoft. Ask which part of the urgency is the date and which part is the quarter their own targets close in.

Here the arithmetic has real inputs rather than sentiment. Four of them, and you can put a number or a written answer against each.

How long until the date that actually binds you. Not the headline date: the earlier of your regulatory-update exposure and your fixed-lifecycle position, worked out from the table and the written answers above.

What a migration costs, over five years rather than one. The implementation quote is the smallest number in this decision. Licence renewal uplift, the users you will add, the second entity, the reporting layer that has to be rebuilt somewhere, and the internal person whose year this becomes are all larger and none of them appear in a proposal. The five-year total cost of ownership is the frame that makes two proposals on different licensing theories comparable at all.

What the estate actually does. An installation doing straightforward multi-entity finance is a different project from one that has become the operational spine of the business. The two cannot be scoped from one template.

Whether the destination is Business Central at all. This is the input most likely to be assumed rather than tested, and the one with the widest cost consequence.

There is a real counter-argument to waiting, and it deserves stating fairly. Deferral is not free. The cost of the move does not fall while you wait, the pool of people who know your installation shrinks every year, and a migration run against a deadline is worse than one run against a plan. But that argues for deciding early and starting on your own calendar, not for starting in the quarter a partner would like to book it in.

What a GP shop has to establish before it can price anything

Four questions, and none of them are about the destination product. You cannot get a comparable quote from anybody until you can answer them, and the fact that you cannot answer them yet is not a reason to let a vendor answer them for you. They are the standing half of the same discipline as the asks that break a rehearsed demo: one forces the vendor to answer against your reality, this one establishes what your reality is.

What has been customised, in a written list. Every modification, why it exists, and who asked for it. Companies that hold this list get honest quotes; companies that do not get an estimate against an unknown, discovered at their expense in month five. A good share of the items usually turn out to be things nobody has used since the person who requested them left.

What the reporting layer is, and where it lives. Every long-running finance system accumulates a reporting apparatus around it — statements, packs, board reports, the spreadsheet the CFO actually trusts. Count them, find out who built each, whether it reads from the system or from an extract, and which would genuinely be missed. That inventory is usually longer and more load-bearing than anyone expects.

What the integrations are, including the ones nobody owns. Bank files, customs portals, a payroll, a warehouse system, a scheduled job somebody wrote. Each one is a separate negotiation with a separate party, and third parties do not move on your timeline.

What the data has to survive as. History is not one requirement, it is three: what must be live and queryable in the new system, what must be readable for audit and for how long, and what can be archived and left where it is. Settling that before you talk to anybody removes the most expensive ambiguity in a migration scope, because "bring the history across" can mean two months of work or twelve depending on who reads it.

Where the destination question goes

Business Central is the obvious answer, and obvious answers are worth testing.

The pricing is public. Microsoft's Business Central pricing page lists Essentials at USD 80.00 per user per month paid yearly, Premium at USD 110.00, and Team Members at USD 8.00. That page also carries a footnote worth quoting before anyone builds a model on those figures: "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." Treat the list price as a starting shape, not as a quote, and note that the licence line is the smaller half of the decision on any product in this band.

The reason to be careful with those figures is not that they are wrong. It is that they answer the smallest question in the decision. A per-user, per-month number tells you nothing about how many of your people need a full seat rather than a limited one, what the implementation costs alongside it, what the renewal looks like in year three, or what the marketplace apps you end up depending on are charged at. Model the licence and the services in the same units or you are comparing a subscription against a project, which is how a proposal that looked cheap in the boardroom becomes the expensive option by year two. What Business Central actually costs a UAE company works through that whole shape rather than the list price alone.

It is also not the only destination, and this is the one place where a GP shop has more freedom than it thinks it has. A move off GP is a rare moment when the incumbent carries no structural advantage at all: you are rebuilding the configuration, retraining the users and moving the data whatever you choose, so the switching cost that normally protects a vendor is simply not there this time round. Staying inside the same product family is a decision, not a default, and it deserves to be made on the same evidence as any other decision of that size.

That is the argument for running this as a real selection rather than as a renewal. Which band of the market you are actually in, who genuinely plays in it in this country, and how to tell a product problem from a partner problem, are decided by the document you put in front of the bidders. Run the shortlist properly and the Microsoft line may well win it, which is a much stronger position to be in than having assumed it.

What to do in the next month

Establish your version line, and therefore which lifecycle regime you are on. Read your row in the table. If it is a 2013, 2015 or 2016 line, the decision was made for you; move to planning. If it is 2018, read the tax releases sentence again and treat your binding date as earlier than January 2028. If you are on 18.x, you have time — use it to do the work above properly rather than to do nothing.

Then get the four inventories written — customisations, reporting, integrations, data — before you invite a proposal. A vendor asked to quote against unknowns will quote against optimism, and the correction arrives later at your cost. If you want the diagnosis run independently of anyone selling you the destination, that is the shape of how we scope a replacement: what you have, what it costs to move, and what it costs to stay, written down before anybody chooses a product.

The dates are not the decision. They are one input into it, and they are the only input the partner sending the email has actually read.

Every date above comes from Microsoft's published Dynamics GP lifecycle page, checked on 9 September 2026. That page carries a document date of 14 January 2024 and was last updated on 7 May 2025. Check it again before you commit a budget.