Migrating GP custom reports, integrations, and ISV add-ons

This is the part that derails projects

Ask anyone who has lived through a difficult ERP migration what went wrong and the answer is rarely the data. It is the Tuesday three weeks after go-live when someone asks where their report went, or the month end that cannot close because a feed from the e-commerce platform silently stopped.

GP has been in most shops for fifteen or twenty years. In that time it grew an ecosystem: SmartLists the controller built and forgot, an FRx report set migrated to Management Reporter (or not), an Integration Manager job that loads payroll hours every other Friday, a Dexterity customization from a partner that no longer exists, an ISV add-on that half the warehouse depends on, and a dozen Excel workbooks pulling from the SQL tables over ODBC. None of it appears in a license count. All of it is load-bearing.

The failure mode is predictable, and it is not unique to GP. Industry-wide, among the ERP projects that went over budget in 2024, the single most commonly named cause was an unexpected need for additional technology, cited by 51.2 percent of respondents, more than staffing, more than consulting fees1. On the schedule side, technical issues (51.2 percent) and data issues (46.3 percent) were the two leading named causes of projects that ran long1. Those are not abstract risks. They are exactly what happens when a report nobody remembered depends on a table structure the new system does not have, or when an integration turns out to need custom middleware that was never budgeted. The project scopes “migrate GP,” prices the data and the software, and discovers the ecosystem one broken workflow at a time after cutover.

The fix is equally predictable: find everything first, decide its fate deliberately, and price the decisions before you commit to a timeline. The median ERP project now takes 15.5 months from decision to stable operation2, and a meaningful slice of that calendar is consumed by exactly the surprises this inventory is designed to prevent. With December 31, 2029 as the practical deadline for GP support and tax updates, you have room to do this properly, and it is the highest-leverage week of the whole project.

Where budgets and schedules actually break

Before walking through the inventory, it is worth looking at why this specific layer of a GP migration is so dangerous. The causes are not evenly spread. They cluster around exactly the things a customization inventory surfaces: technology nobody scoped, technical integration work nobody estimated, and data issues nobody found until the new system rejected the feed.

Read those four bars as a single story. “Unexpected need for additional technology” is what happens when a report, an integration, or an add-on turns out to require middleware, a paid connector, or a rebuild nobody scoped. “Technical issues” is what happens when a Dexterity customization or an eConnect procedure does not translate cleanly into the new platform’s architecture. “Data issues” on both sides of the ledger, the third and fourth largest named causes of overruns, is what happens when a feed’s source data was never clean enough to migrate in the first place. None of the top named causes in either column is “the core ledger data was hard to move.” They are all, in one form or another, the customization layer.

How to inventory everything around GP

Work through these seven layers. For each item, record what it does in business terms, who uses it, how often, and what breaks if it disappears. This inventory step is not optional and it is not quick; treat it as its own project phase with its own owner, because it is where the causes above get named and priced instead of discovered at cutover.

SmartLists and SmartList Builder. Export the list of SmartLists per company, then separate stock lists from custom ones. SmartList Builder objects are stored in their own tables and are queryable, so a partner can pull the full custom list along with the underlying tables each one touches. The count is usually shocking; the number actually used monthly is usually under twenty.

Management Reporter and legacy FRx. List every report definition, row format, and reporting tree. If any reports still exist only in FRx, flag them red immediately: FRx has been unsupported for years, and those definitions need to be captured now, not at cutover. Management Reporter itself is also years past its own useful shelf life as a standalone product, so treat both as a single “financial reporting” bucket to migrate off entirely. These are your financial statements, so this layer gets finance sign-off, not just IT’s.

Integration Manager and eConnect. Integration Manager holds defined integrations you can list directly from its interface: a wizard-built job that maps a source file to GP’s import tables. eConnect integrations are code, not configuration, so they will not show up in any UI, you have to search for the eConnect stored procedures being called (their names typically start with taSop, taRm, taPm, and similar prefixes for sales, receivables, and payables transactions) and trace back to the applications calling them. Together these represent every system that pushes data into GP: payroll hours from a time clock, web orders from an e-commerce platform, bank files, expense tool exports. Each one implies a counterpart integration that must exist on the new system’s first day, or that process stops.

Dexterity customizations and modified forms. Every GP install lists third-party products and customization dictionaries in the DYNAMICS.SET file, which names every dictionary loaded alongside the core application. Each Dexterity modification changed how GP itself behaves, sometimes subtly, like a validation rule or a field default, sometimes structurally, like an entirely custom entry window. These are the hardest items to even understand, because the partner who wrote them may be gone and there is often no design document at all; sometimes the only way to find out what a modification does is to ask the person who uses that screen every day to walk through it step by step.

Modifier with VBA customizations. Distinct from Dexterity, Modifier with Visual Basic for Applications lets a partner or an internal developer add fields, validation, and automation on top of a standard GP window without touching the core dictionary. These are more common than Dexterity mods in mid-market shops because they were cheaper to build, and for the same reason they are frequently undocumented one-off scripts written by someone who left years ago. List every window with a VBA customization attached and what the code actually does before assuming it can simply be turned off.

ISV add-ons. Fixed assets, EDI, advanced distribution, field service, credit card processing, document delivery, bank reconciliation extensions. List each product, its vendor, whether the vendor is still in business and still supporting the current version, and what data lives in its own tables outside core GP, because that data needs its own archive decision too.

Excel, ODBC, and refreshable reports. The shadow layer. Ask each department for the workbooks they refresh against GP; separately, check SQL Server for logins used by Excel connections, since some of these will not be volunteered by the people using them because they do not think of a pivot table as “an integration.” These never appear in any official inventory and they are how half of finance actually works day to day.

Scheduled jobs. SQL Agent jobs, Windows scheduled tasks, and PowerShell scripts touching the GP databases: nightly extracts, posting automation, backup-adjacent scripts, alerting on failed batches. Whoever set them up is often gone; the jobs are still running, silently, until the databases they depend on disappear.

Expect the full inventory to land between 100 and 300 items for a typical mid-market GP shop. Do not panic at the number. The next step shrinks it fast.

Rebuild, replace, or retire

Every item on the inventory gets exactly one of three labels, and the decision should be made deliberately, item by item, not defaulted to “rebuild everything so nothing breaks.”

Ten well-understood rebuilds are a plannable project with a real budget line. A hundred vaguely scoped “customizations” carried forward on faith are how a project ends up matching the 51.2 percent of 2024 ERP projects that named an unexpected technology need as a top budget overrun cause1.

Two forcing questions sort items quickly. “Who ran this, or relied on this feed, in the last 90 days?” retires more than any other question, because usage data is harder to argue with than institutional memory. And “what business decision does this output feed?” separates reports people glance at from reports the business actually runs on, which tells you how much rebuild rigor a given item deserves.

Rebuild against the new model, not one-to-one

For everything that lands in the rebuild column, resist the instinct to port it faithfully. A GP report or integration encodes GP’s own structure: its account segment layout, its batch posting model, its open-versus-history table split (the reason GP has both a GL20000 open table and a GL30000 history table), its per-company database design. Recreating that shape inside a new system means paying to preserve GP’s constraints after you have already paid to escape them.

Instead, restate the requirement in business terms and rebuild against the new system’s model. “We need the GL30000 extract joined to the account index master, refreshed nightly” is not a requirement, it is a description of how the old system happened to store the answer. “We need daily gross margin by product line” is the actual requirement. The first version drags GP’s plumbing into the new system. The second is usually a saved report or a small query in the new platform, built in a day by someone who never has to know GL30000 existed.

The same discipline applies to integrations. An Integration Manager job that loads a CSV of web orders into GP batches should not become a CSV loader for the new system just because that is the pattern everyone is used to. The new platform almost certainly exposes a real API, and the right rebuild is direct: orders flow in as orders, with validation and error handling that a decade-old Integration Manager job never had because the tool did not support it. The migration is your one chance to fix the brittle parts, and the marginal cost of fixing them during a rebuild you are already paying for is small compared with fixing them later as an emergency.

The same logic applies to direct SQL. Plenty of GP shops have a report or a script that queries the SQL Server tables directly, bypassing GP’s own object model entirely, because it was faster to write that way years ago. Those queries are the most fragile items on the whole inventory: they depend on exact table and column names that the new system will not have, they often silently include or exclude records in ways nobody fully documented, and they are the most likely candidate to be quietly resurrected as a stopgap after go-live rather than properly rebuilt. Flag every direct-SQL report and integration explicitly and require a named owner to sign off on its replacement, the same way finance signs off on Management Reporter statements.

Do not recreate GP inside the new system

The last risk is cultural rather than technical. Teams that spent two decades in GP will ask the new system to behave like GP: the same screens, the same batch workflow, the same report layouts down to the pixel. Every accommodation like that is itself a customization, and enough of them turns the new ERP into an expensive GP costume that is just as hard to maintain and harder to upgrade than the system it replaced.

Hold a simple line: the new system’s standard way wins unless there is a documented business reason it cannot. Reports get rebuilt to answer the underlying question, not to match the old layout pixel for pixel. Workflows follow the new platform’s design unless a real constraint, a regulatory format, a customer-mandated document, a genuine operational difference, demands otherwise. Each exception goes on a list with a named owner and a stated reason, and that list gets reviewed periodically by someone with the authority to say no.

Done this way, the customization layer stops being the thing that derails the project and becomes the thing that finally gets rationalized. Most companies come out the other side with a fraction of the moving parts they had around GP, each one documented, owned, and built on a platform that will still be supported well past 2031. That, more than the core ledger data, is what determines whether a GP migration lands on time and on budget, or joins the roughly one in three ERP projects that runs long2.