INDEPENDENT PRODUCT — NOT AFFILIATED WITH OR ENDORSED BY MICROSOFT hello@erpdataarchive.com
eda ERPDataArchive

GUIDES / BACKUP VERSUS ARCHIVE

Is a Dynamics GP SQL backup enough after migration?

Keep the backups. Do not confuse recoverability with usable historical access.

Updated 28 July 2026 / 7 minute read

What the backup preserves

A full SQL Server backup can preserve the DYNAMICS database and company databases at a point in time. It retains source tables, keys, custom objects and records that a selective export might miss. For disaster recovery and evidentiary retention, that original backup is valuable.

The backup should remain part of the decommission package even when a separate archive is created. Store the backup, the SQL Server version and collation, encryption keys where applicable, GP build information, third-party dictionaries, report definitions and restore instructions.

What a backup does not provide

A controller cannot double-click a .bak file and search for an invoice. Answering a question requires:

  1. 01A compatible SQL Server instance with enough storage.
  2. 02Permission and expertise to restore each database.
  3. 03Knowledge of the GP table model and company setup.
  4. 04Queries that join work, open and history records correctly.
  5. 05A secure way to deliver the answer.

If the restore is attempted years later, installation media, credentials, encryption certificates or staff knowledge may be missing.

Why raw tables are difficult to use

GP table names and fields are compact and system-oriented. A single business document can span header, line, distribution, apply, note and master tables. Similar records may live in different tables depending on status or history transfer. Dates, padded character fields, multicurrency amounts and document type codes require deliberate interpretation.

A SQL backup preserves those facts accurately. It does not translate them into a usable historical application.

Test the restore before shutdown

  • Restore DYNAMICS and every in-scope company database to an isolated SQL Server.
  • Run DBCC checks and record the result.
  • Confirm users can identify companies and fiscal periods.
  • Test representative GL, AR, AP, SOP, POP and inventory queries.
  • Verify third-party and custom tables are present.
  • Document the SQL version, collation and any encryption dependencies.
  • Record backup checksums and store copies in separate failure domains.

Use both when the records matter

The strongest decommission package often contains two layers:

Layer 01

The original SQL backups preserve the source system in its native database form.

Layer 02

A reconciled archive gives ordinary users fast, documented access without restoring GP infrastructure.

The archive handles expected questions. The backup remains the last-resort source artifact if a novel technical or legal request requires native evidence.

Backup-only decision test

A backup-only strategy may be reasonable when retention is short, historical access is extremely rare, a tested SQL recovery service is under contract and no ordinary business user needs self-service access. It is a poor fit when auditors, tax teams, customer service or operations expect recurring historical questions.

Ask the person proposing "we will keep the backups" to restore one and answer a representative invoice question within the response time the business expects. The result is a better planning input than the storage cost.

See what the backups would need to cover.

The free assessment inventories all GP companies, history ranges and unknown tables while the live environment is still available.

Request the free assessment