Software companies

Dynamics GP end of support: what ISVs and add-on vendors should do

By SourceX Editorial · Updated October 9, 2026

Short answer

When Dynamics GP reaches end of support, ISVs and add-on vendors have five realistic paths: port the product to Business Central, keep maintaining it for the remaining GP base, sell the product line, sunset it, and in every case preserve and assess the records it produced. Choose by where customers are moving and what your archives hold.

Key takeaways

Microsoft has published separate GP milestones for sales, support and security updates; confirm current dates on Microsoft's lifecycle pages before planning.
Porting to Business Central is a new product build, not an upgrade, so judge it against your customers' actual migration plans.
Selling or sunsetting a GP product line still leaves source code, support history and customer contracts to decide on.
Customer databases sent to support over the years are customer data and must be found and handled under your contracts.
Years of GP add-on engineering and support records can become a licensable asset if preserved before old systems are retired.

What end of support means for an add-on vendor#

End of support means your GP add-on's market shrinks on a schedule you do not control: as customers move to Business Central or another ERP, each migration ends a maintenance contract unless you have something for them on the new platform. Microsoft has published a GP lifecycle with separate milestones for new sales, product support and security updates, so take current dates from Microsoft's lifecycle documentation rather than partner blogs.

The channel moves with the customers. The VARs that resold your add-on are building Business Central practices, and their recommendations will follow the ISVs with a credible product there. Customers still on GP will ask for your roadmap long before support ends, and a vague answer pushes them toward competitors.

The decision also has a data side that is easy to miss. Your company holds years of source code, issue histories, support tickets and release records tied to GP, plus customer files collected during troubleshooting. What happens to those records depends on the path you choose.

Five options, compared#

The five options are port, maintain, sell, sunset, and preserve and license records, and the last one combines with any of the other four. Most ISVs end up choosing two: a product path and a records path.

Compare the options against customer evidence, not instinct. A short survey of your installed base on target ERP, timing and must-have functions usually settles whether a port can pay back.

Five options, compared
Option	Fits when	Main risk	What happens to records
Port to Business Central	Customers are migrating and want the same function	A rebuild in AL competes with native features and other apps	GP code and history become the design reference for the new product
Maintain for the GP base	Many customers will stay on GP late into the lifecycle	Shrinking revenue and a team tied to an aging stack	Archives keep growing, so plan their future now
Sell the product line	Another ISV or VAR wants your customers or IP	Value falls as the GP base shrinks	The purchase agreement must say who keeps code, tickets and contracts
Sunset with a migration path	A partner product covers your function on the new platform	Customer goodwill and contract obligations at shutdown	Archives risk deletion when systems are switched off
Preserve and license records	Engineering and support history is deep and well linked	Rights review and preparation take effort	Records are kept, scoped and licensed with customer data excluded

A timeline without surprises#

A timeline without surprises works backward from Microsoft's milestones and from your customers' own migration plans. Use phases rather than fixed dates in the internal plan, and attach Microsoft's current dates whenever you share it with customers or partners.

Now: survey customers on ERP plans, announce your direction, and limit new GP work to compliance and year-end updates.
Before most customers migrate: ship the Business Central product or the migration partnership, and offer transition terms to maintenance customers.
Before Microsoft's support milestone: set your own end-of-maintenance date, give contractual notice and agree how remaining customers will be served.
Before security updates end: retire GP build and test environments, archive code and records, and close remaining support channels.
At every phase: confirm which records you will keep, where they will live and who owns the decision.

Contracts to read before announcing anything#

The contracts to read before announcing anything are your customer license and enhancement agreements, your reseller agreements and any source code escrow arrangements. Together they decide how much notice you owe, what customers can claim if you stop, and what your partners may do next.

Contracts to read before announcing anything
Agreement	What to check
Customer license and annual enhancement plans	Support commitments, renewal terms, notice periods and refund rules
Reseller and VAR agreements	Exclusivity, territory, termination notice and who owns the customer relationship
Source code escrow	Release conditions such as discontinued support, and whether the deposit is current
Microsoft partner and marketplace terms	Obligations for listings and certifications on the new platform
Purchase agreements for acquired add-ons	Inherited support promises and restrictions on records

What records a GP add-on vendor has accumulated#

A GP add-on vendor usually holds deep engineering and support history: Dexterity and .NET source code with its review history, issue trackers covering each GP release and year-end update, support tickets diagnosing posting errors and integration failures, and partner documentation and training material.

Some of what sits in those systems is customer data. Support teams often received company databases and backups to reproduce problems, and tickets may include screenshots of ledgers and payroll records. Find these copies, check contracts for return or deletion duties, and keep them out of any reuse.

The rest is your company's record of expert work on accounting software: how problems were diagnosed, which fixes worked and why designs changed. Preserve it in a durable format before old ticketing tools, build servers and file shares are retired along with the GP product.

Illustrative example: a project accounting add-on vendor picks two paths#

Illustrative: a fictional ISV sells GP add-ons for project accounting and job costing to construction contractors through a network of VARs. Its records sit in an on-premise issue tracker, a hosted help desk, a Git repository migrated from older version control, and a shared drive of implementation guides.

The CEO chooses to port the core job costing function to Business Central and to sell the remaining GP maintenance contracts to a VAR that will support them to the end. The purchase agreement leaves source code, issue history and support tickets with the ISV and transfers only customer contracts and current support duties.

Before the old tracker is retired, the company exports issues, tickets and code history, deletes customer databases found in ticket attachments, and starts a metadata-only fit check on whether the archive could be licensed.

How SourceX approaches retiring product archives#

SourceX approaches a retiring product's archive like any other supply. The Supply step of the SourceX five-step transaction catalogs systems, years and record families from metadata, and the Rights step separates company records from customer data such as databases received for troubleshooting, which is generally excluded.

If a package proceeds, Preparation removes customer names and financial details from tickets and notes, the ISV approves the scope, and Delivery can come from the ISV's own storage. The SourceX Evidence Packet records provenance and release authorization, which matters when a product line has been sold and the buyer of the contracts later asks what was kept.

Frequently asked questions

Should we stop selling the GP version of our add-on now?

That depends on where Microsoft's sales milestones stand and on your customers' plans. Many vendors stop new GP sales once the platform itself is no longer sold to new customers, while continuing to serve existing ones. Check your reseller agreements before changing price lists or availability.

Do we owe customers source code if we stop supporting the product?

Only if an escrow agreement or license term says so. Escrow arrangements often release code when the vendor discontinues support or goes out of business. Read each agreement's release conditions, make sure deposits are current, and plan the notice you will give before announcing an end date.

Can we license support tickets that mention customers' GP data?

Possibly, after preparation. The tickets are your records, but they often quote ledger entries, employee names or vendor details from customer systems. Those details must be removed, and attached customer databases excluded entirely, before any scope is approved. Customer contracts may add further limits.

What happens to the records if we sell the GP product line?

Whatever the purchase agreement says. Buyers of a product line often want the code and customer contracts, while the seller may keep historical tickets and engineering records, or the reverse. Decide deliberately, write it into the agreement, and make sure retained records stay accessible after the transfer.

Is a Business Central version a new product for data purposes?

Largely, yes. The new code, issues and support history start fresh on a different platform, though design decisions will reference the GP product. Keep the two archives distinguishable so you can describe each accurately in any later sale, audit or licensing review.

Related resources

See if your company qualifies

A short company assessment. No data uploads are needed.

Inventory your GP-era records Talk to SourceX