Should you keep Dynamics GP running read-only after migration?

Why read-only GP feels safe

The application is familiar, the old SmartLists still exist, and users can see the records in the same windows they used before migration. Keeping the environment intact also avoids a hurried decision about reports, attachments and third-party tables during go-live.

Those are good reasons for a temporary parallel period. They are weak reasons for an indefinite operating model.

The full cost is larger than the GP screen

A read-only GP environment still depends on the surrounding stack. Include each of these when comparing it with an archive:

• Windows Server and SQL Server licensing or hosting allocation
• Dynamics GP license and use-right questions for the customer contract
• Virtual machine, storage, monitoring and backups
• Operating system, SQL and endpoint patching
• Identity, remote access and multifactor authentication controls
• Recovery testing and someone who knows how to restore the environment
• GP partner or internal specialist time when reports or logins stop working

A server that receives three lookups a month still needs the same security and recovery discipline as a busier server.

Read-only stops posting, not exposure

Removing posting rights prevents ordinary users from changing accounting records. It does not remove vulnerabilities in Windows, SQL Server, GP, remote access tools or third-party components. The system still contains customer, vendor, employee and financial history.

The label also needs technical enforcement. A process is not read-only because staff have been told not to post. Disable or remove write-capable application access, restrict SQL permissions, document any service accounts and test the controls.

Microsoft plans to end Dynamics GP product enhancements, regulatory updates and technical support on 31 December 2029, with security updates ending on 30 April 2031. Version-specific lifecycle dates may be earlier. Contract-specific subscription and SPLA rights need separate review.

A controlled bridge is often the best use

Keep GP available for an agreed period after go-live while users test the historical solution against real requests. Six elements make the bridge useful:

1. 01Name an owner for the old environment.
2. 02Set the planned shutdown date before go-live.
3. 03Route historical questions through the archive first.
4. 04Log anything the archive cannot answer.
5. 05Fix missing coverage while the source is still available.
6. 06Require reconciliation and management approval before shutdown.

The rehearsal and final extraction runs in ERPDataArchive are designed for this pattern. The first lets users compare. The second captures the approved cutover state.

Read-only GP exit checklist

• ✓Final source state is frozen or captured in a verified SQL snapshot.
• ✓All required companies, modules, notes and agreed custom tables are archived.
• ✓Row counts and fiscal-year trial balances reconcile.
• ✓AR, AP and inventory control totals are reviewed where included.
• ✓Users can find documents and run the recurring historical queries.
• ✓Archive permissions, encryption and backups are tested.
• ✓Database backups and installation media are retained under the legal retention policy.
• ✓The controller, IT owner and executive sponsor approve decommissioning.

See Microsoft's Dynamics GP support notice for current product dates. Review licensing and retention obligations with qualified advisers.