ERP replacement. Microsoft Dynamics GP
Leaving Dynamics GP for a cloud system your business owns
In short
- Black Badger Software Solutions is a custom software company in Clearwater, Florida that replaces Microsoft Dynamics GP with a cloud system your company owns outright, on hosting and database accounts in your name, never a reinstall or a new on-premise server.
- We were never a Microsoft Dynamics GP partner and we have no Dynamics GP engagement on record, so nothing rides for us on which way you go, and we do not configure, patch or administer Dynamics GP for anyone.
- Leaving means GP's data comes out of SQL Server directly with every key intact, the Dexterity, VBA, SmartList, eConnect and add-on customizations are read for the rules they hold and rebuilt as code, and GP keeps closing the books until a period reconciles on both sides.
- The two replacements we publish outcomes for went live in six weeks and in sixteen weeks, and the runway for yours goes in the written scope once we have seen your data.
- After launch the system costs roughly $100 to $200 a month to run for a smaller company, and $2,000 to $3,000 a month at enterprise scale. Those are hosting and service bills you pay the providers directly, with no license and no per-user fee.
Microsoft Dynamics GP, Great Plains before Microsoft bought it, is an on-premise ERP that runs on SQL Server. General ledger, receivables and payables, inventory, sales and purchase order processing, payroll, and a deep bench of add-on products from independent vendors. A lot of mid-sized companies have closed their books on it for many years, and it earned that loyalty.
Microsoft has announced the end of it. Its published lifecycle ends product enhancements, tax and regulatory updates and technical support on December 31, 2029, with security updates, where Microsoft judges them necessary, until April 30, 2031. It has stopped selling GP to new customers, and its own recommended path is Dynamics 365 Business Central. So every GP company is going to move. The real decision is where, and whether the next system is one more product you rent or one you own.
Where we stand
Do you implement or support Microsoft Dynamics GP?
No. We were never a Microsoft Dynamics GP partner, we have no Dynamics GP engagement on record, and we will not pretend otherwise. What we bring is the build side, the cloud system your operations would move into, and a straight answer on whether Business Central is the better place to land.
We were partners of other platforms, monday.com, Smartsheet, Wrike and Zoho among them, and we ended those partnerships to build replacements. So the GP work we take is replacing it, on accounts in your name. We do not install or upgrade GP, write Dexterity, host it on a server or take an admin retainer. Every GP company has to move somewhere before Microsoft's end of support, and the section below says when Business Central is the honest answer.
Where it fits
Where does Dynamics GP fit?
We sell no Microsoft Dynamics GP licenses and take no referral fees, so this is not a hit piece. These are the cases where keeping it is the honest advice, and if yours is one of them, we will say so on the call.
You're mid-year on GP payroll with a stable close and nothing else breaking. GP stays supported under Microsoft's announced lifecycle until the end of 2029, and moving in a hurry is worse than moving on a plan. Use the time to decide well.
Your finance team wants a packaged Microsoft ERP with a familiar chart of accounts, Microsoft's own migration tooling for GP data, and the Office and Power BI ties it already leans on. For that company Business Central is a sensible landing place, and we'll say so.
You run multi-entity consolidation, intercompany and a statutory close that an auditor or lender expects to come out of a recognized ERP. That ledger should land in a recognized product, most often Business Central, and the operational layer around it is what gets built to fit.
Your GP was bought to keep the books and that's all it does, with little customization and few add-ons. The move to Business Central is closest to like for like there, and a custom replacement may not repay itself.
Where it breaks
Where does Dynamics GP break down?
The failure modes below are the ones that show up again and again as a company grows.
It's ending. After Microsoft's announced end of support there are no tax table updates, no regulatory changes and no fixes. That lands hardest on companies running US payroll in GP, because the year-end tax changes stop arriving.
It lives on a server. GP was built for a Windows client on a local network talking to SQL Server, and remote access usually means remote desktop or a hosted server someone else runs. Every person outside the building, every field crew and every customer is a license, a VPN or a spreadsheet emailed back and forth.
Customization is layered in tools few people still write. Dexterity, the language GP itself is built in. Modifier with VBA on the forms. SmartList and SmartList Builder for queries, eConnect and Integration Manager for imports, and custom SQL views and stored procedures besides. The person who wrote them has often left, and every upgrade had to be retested against all of it.
Much of what the business depends on is an add-on from an independent vendor. Each has its own license, its own tables in the company database and its own upgrade timing, and each now has to decide its own future because GP's has been decided. Some of the data you need lives in their tables, not GP's.
Reporting runs through SmartLists, refreshable Excel reports and Management Reporter, so the daily operational question (what's late, which job is losing money) gets answered by exporting. That's the same shadow system every ERP ends up with, running beside a database that never leaves the building.
The replacement
What does replacing Microsoft Dynamics GP look like?
This splits two ways. If GP keeps ordinary books for one or a few companies, the whole thing can go, ledger included. General ledger, receivables, payables, inventory, purchasing, sales orders and the operational work around them move into one system built for your company. If you run multi-entity consolidation and a statutory close that an auditor expects from a recognized ERP, the ledger moves to a product like Business Central and we build the operational layer around it, posting back through its API.
Either way the new system runs in the cloud, on hosting and database accounts in your name. Not a reinstall, not a new on-premise server, and not GP lifted onto a rented virtual machine. That last option buys a few years and keeps every problem on this page, so we don't build it.
Migration reads SQL Server directly, and that's the one real advantage GP gives you on the way out. The company databases are ordinary SQL Server tables, so customers, vendors, items, open documents and posted history come out with every key intact and no export wizard in the way. Everything gets mapped into the new structure in a document you approve before anyone writes a row, and GP stays live until a closed period reconciles on both sides.
You own the result. Code in a repository in your name, the database and hosting in your name, unlimited users including people outside your company, and no product lifecycle on someone else's calendar. We're added as administrators so we can build it and support it, and you can remove us whenever you want.
The stakes
What does it cost to get this wrong?
More than the software. A replacement that goes badly costs you the one thing the old system was still doing, a single place your team agrees on. The failures below each turn a rebuild into a year of parallel systems, so they are the ones we plan around.
GP moves posted journal entries from its open-year tables to its history tables only when a year is closed, so a company that put off year-end closes has several years sitting together in the open tables. Extract them without rebuilding balances by year and period and the opening figures won't tie to any trial balance GP printed, and finance signs nothing off.
The table names are codes, RM00101 for customers and PM00200 for vendors among hundreds of others, and the add-ons bring their own. Map them by guesswork and you get history that loads cleanly and means nothing, or a commission, a landed cost or a project balance that quietly lived in an add-on's table and never came across.
Moving the books and leaving the work behind. Replace GP's ledger, leave scheduling, jobs, quoting and the customer view in spreadsheets, and the shadow system survives the move. You'll have changed products and kept the problem, on a deadline Microsoft set.
The order of work
What happens, in what order, when you leave Dynamics GP?
Each step exists because skipping it is how the previous attempt failed. The sequence is fixed. The runway is not, and it goes in your written scope once we know the shape of your data rather than on this page as a calendar promise.
- 01
Inventory of what GP really does
We list every module with real activity, every add-on and what it stores, and every customization still firing. Dexterity customizations, VBA on the forms, SmartLists, eConnect and Integration Manager jobs, SQL Server jobs, and the reports people actually open. It's common to find add-ons still on a maintenance plan that nobody has opened since the last upgrade.
- 02
Extraction straight from SQL Server
GP's data sits in SQL Server, one database per company plus a system database for users and setup, so it comes out by query with every key intact. Customers, vendors, items, open and posted documents, and general ledger history by year and period, with currency and company carried on every row. Add-on tables come out the same way. We don't copy the SmartLists. They're queries, so what gets recorded is the question each one answers.
- 03
The honest scope
This one decision shapes everything after it. If the accounting is ordinary, all of GP goes and the ledger is part of the new system. If consolidation, a statutory close or an auditor's expectations justify a recognized ERP, the ledger moves to Business Central or a product like it, and the operational layer gets built around it. We take a position on which one applies before we scope anything.
- 04
Build in the cloud while GP keeps running
The new system gets built on cloud accounts in your name while GP keeps closing the books, reading from SQL Server on a schedule so its data stays current. Jobs, scheduling, quoting with real pricing rules and the customer-facing view come first. That's where the spreadsheets are, and where remote desktop access to GP hurts most.
- 05
Reconcile a closed period, then retire the server
Nothing gets switched off until finance has a closed period that matches line for line on both sides. Open orders, receivables, payables and inventory get checked at the same time. Then the cutover happens, the GP databases are kept as a read-only archive, and the server, its SQL Server license and the GP maintenance plan come off the list.
Limits
Where do we draw the line?
Saying this out loud is cheaper for both of us than finding out in month two. If one of these is what you actually want, we are the wrong firm and we will say so on the first call.
- We won't reinstall GP, upgrade it onto a new server or host it for you. What we build runs in the cloud on accounts in your name, and putting GP on a newer server doesn't move Microsoft's end of support by a day.
- We won't talk you out of Business Central when it's the right call. If you need a recognized ERP for consolidation or for your auditor, we'll say so plainly and build the operational layer around it.
- We won't switch anything off before finance signs off on a period that reconciles on both sides. A cutover taken on assurances, with Microsoft's date as the excuse, is how an audit trail ends up with a hole in it.
Questions
What do people ask before leaving Microsoft Dynamics GP?
When does Microsoft end support for Dynamics GP?
Microsoft's announcement sets December 31, 2029 as the end of product enhancements, tax and regulatory updates and technical support, and April 30, 2031 as the end of security updates, which it says it will release only where needed. It has also stopped selling GP to new customers. GP keeps running after those dates. What stops is the stream of fixes and tax changes, which is why payroll users feel it first. Check Microsoft's lifecycle page for the current wording, because the support date has moved once already.
Do you work with on-premise Dynamics GP?
Only to move off it. GP is on-premise by design, so every GP replacement is an on-premise to cloud move. We read its SQL Server databases, run the new system beside it, and retire the server at cutover. We never install, upgrade, patch or host GP, and what we build always runs in the cloud on hosting and database accounts in your name.
Shouldn't we just move to Business Central?
Sometimes, yes. Business Central is Microsoft's own path for GP companies, it has migration tools built for GP data, and for a company that wants a packaged Microsoft ERP with a recognized ledger it's a sound choice. It's still a product you rent per user, set up by an implementation firm, extended in its own language and updated on Microsoft's calendar. If what drove you to spreadsheets on GP was the operational fit, Business Central won't change that by itself. If you choose it, we can build the operational layer around it.
We have years of Dexterity and VBA customizations. Do they come with us?
The rules do. The code doesn't. Dexterity, VBA and the SQL behind your SmartLists and eConnect jobs get read for what they enforce, and the rules that still matter get rebuilt as tested code. The customizations that existed only to bend GP around your business go away with GP.
What about payroll?
Plan it first, because tax table updates are exactly what Microsoft's end of support takes away. We don't write payroll tax engines. Tax tables are a product someone should be paid to keep current, so GP payroll belongs with a payroll service, moved at a year boundary, with the new system sending it hours and taking the journal back. The timing of that move often sets the timing of everything else.
What happens to our historical financial data?
It stays available and it stays reconcilable. Posted history comes out of SQL Server by year and period with its keys intact, so historical figures still tie to what GP reported. The GP databases are kept as a read-only archive your auditor can query without a GP login, and closed periods reconcile line for line before anything gets switched off.
What does replacing Dynamics GP cost?
It depends on which modules and add-ons are in real use, how many companies and users are involved, and what has to keep connecting, so we don't publish a figure for the build. We do publish sourced ranges for what a NetSuite implementation costs by company size, a useful yardstick for any packaged ERP. After a strategy call you get a written scope naming every deliverable and what it costs, measured against what a move to another packaged ERP would cost you. What we do publish is the cost of running the result. After launch the system costs roughly $100 to $200 a month to run for a smaller company, and $2,000 to $3,000 a month at enterprise scale. Those are hosting and service bills you pay the providers directly, with no license and no per-user fee.
Who owns the system, the code and the accounts?
Your company does. The repository, the database, the hosting and the sending domain all get created in your name at the start of the build, and we're invited in as administrators so we can work. You can remove us at any point. No fee, no handover charge, no license reverting to us. GP companies know why that matters. A vendor just set the end date on the system that runs their business, and owning the next one means nobody else gets to do that again.
Related
Coming from a different tool?
The same exit treatment for the other platforms people leave, and the pages that explain the custom model itself.
Where did Microsoft Dynamics GP stop fitting?
Book a strategy call, or send a short note about the workarounds your team runs today. If keeping Microsoft Dynamics GP is the right answer, you will hear that first.