---
title: Access to PostgreSQL Migration: Data and App Checklist | Remqa
url: https://remqa.com/blog/access-to-postgresql-migration
updated: 2026-11-12
---

[Home](https://remqa.com/) / [Blog](https://remqa.com/blog) / Access to PostgreSQL Migration: Data and App Checklist

Data migration guide

# Access to PostgreSQL migration: move the data and the workflow

Plan an Access to PostgreSQL migration with deliberate text exports, lookup IDs, attachment extraction, schema checks and application cutover tests.

Remqa · November 12, 2026 · 5 min read

**Short answer:** Migrate Access to PostgreSQL by inventorying both the database and the application, exporting table data with explicit settings, rebuilding the target schema, and validating relationships before switching users. Treat forms, reports, macros, attachments and query logic as separate work, not as features carried by a CSV file.

- Choose unformatted table or query exports deliberately
- Preserve lookup IDs and extract attachments separately
- Rebuild constraints and test new generated identifiers
- Prove the operator workflow before retiring Access

By the Remqa engineering team · Last updated November 12, 2026

The data imports successfully, but the person who runs the business still cannot finish an order. The missing part is the Access form, a saved query, an attachment or a button that ran several updates. That is the central risk in an Access to PostgreSQL migration. Moving table rows is one workstream. Replacing the application around those rows is another.

Start by recording what people actually do in Access. Then choose an export and validation route that preserves the information needed for those tasks. This guide uses Microsoft's text-export behavior and PostgreSQL 17 import rules as concrete boundaries. The migration sequence is an engineering recommendation, not an automatic conversion guarantee.

## Inventory the application before exporting tables

List tables, saved queries, forms, reports, macros and modules. For each operator task, identify the records it reads, the records it changes and the output it produces. Ask users to demonstrate a normal case and an exception. A printed report or manual correction can be just as important as the main entry screen.

Microsoft's export-all-data documentation separates table data exported through TransferText from other object definitions saved through SaveAsText. Those definitions can help an engineer inspect existing behavior. They are not replacement PostgreSQL screens or executable translations of the original workflow.

Keep an unchanged database copy and record which version the exports came from. Inventory linked data sources separately so the team knows where the authoritative records live. Do not assume the visible database file describes every external dependency.

## Choose text exports by behavior, not filename

Access offers formatted and unformatted text exports. For tables and queries exported without formatting, you can choose delimited or fixed-width output. Microsoft documents that unformatted exports include all fields and records in the underlying object, including hidden columns and filtered rows. A query still defines its own underlying result set, so review its selection logic.

Formatted exports instead follow the displayed fields and records and respect column formatting. That can be useful for presentation, but it is a different extraction contract. Select the route intentionally rather than exporting the view that happens to be open.

| Access behavior | Migration consequence | Recommended check |
| --- | --- | --- |
| Unformatted lookup fields export lookup IDs | The file may contain keys rather than displayed names | Export and reconcile the referenced lookup table |
| Calculated expressions export results | The calculation itself is not in the data file | Document and rebuild required logic separately |
| Attachments and OLE contents are omitted | A row export is not a file migration | Use a separate extraction and ownership manifest |
| Unformatted Yes/No exports use 1 and 0 | Raw values need an explicit Boolean conversion rule | Test true, false and missing values |

Save the delimiter, text qualifier, field order, header choice and encoding with each export. Inspect representative records before loading. Include accented names, quotes, line breaks and long notes. Access cannot append an export to an existing text file, so keep each extraction as a distinct named artifact rather than assuming it extends an earlier batch.

## Preserve relationships and complex fields deliberately

A displayed customer name is not a reliable replacement for its stored customer ID. Keep source identifiers and map each relationship explicitly. If target identifiers change, maintain a source-to-target mapping table. Use that mapping when rebuilding child records and when tracing a validation issue back to Access.

Access multivalued fields are exported as a list of values separated by semicolons and enclosed in double quotes by default. Do not treat that list as if it were already a relational child table. Decide whether the target needs one row per selected value, and preserve the owning record and lookup identity during conversion.

Extract attachments separately. Record the parent table, source record ID, filename and destination reference. Validate that every migrated reference opens the intended file. Keep access restrictions in the target design rather than placing private files in a broadly readable folder.

> **A table export is not a complete application backup.** Preserve the source database and required object definitions. Reconcile files, relationships and workflow logic separately before declaring the migration complete.

## Create a target schema and a staging boundary

Write down the intended target type for every field. Make deliberate choices for exact numeric values, dates, text and Boolean values. Do not infer business meaning from a column name alone. Keep postal codes and external identifiers as text when their formatting is meaningful.

Create the destination tables before import. PostgreSQL COPY writes into an existing table. A supplied column list maps input fields in order, while omitted destination columns receive defaults. Explicit column lists make the load contract easier to review than relying on incidental table order.

For awkward source values, load into a restricted staging area and transform into typed destination tables. Keep the raw value and an explanation when conversion fails. Do not quietly replace an invalid date with a blank value just to finish the load.

## Validate COPY, nulls and generated IDs

A filename used by server-side COPY is read from the database server's viewpoint, not the operator's laptop. Choose an import route with the right file access. Declare encoding and CSV options explicitly. PostgreSQL's CSV defaults distinguish an unquoted empty field, used for null, from a quoted empty string. Verify what Access actually emitted rather than assuming the same convention.

COPY FROM invokes destination triggers and check constraints. Review their effects in a test database before a production import. Rehearse any controlled changes to load behavior and restore the intended configuration before users start writing.

If the target uses identity columns, remember that PostgreSQL generates their values from implicit sequences. Identity alone does not guarantee uniqueness. Use the appropriate primary key or unique constraint. After preserving historical IDs, deliberately configure and test sequence state so a new application insert does not collide with imported data.

## Test the workflow, then control cutover

1. Compare counts for every source table and explain exclusions.
2. Check duplicate IDs, missing parents and unexpected relationship gaps.
3. Reconcile important numeric totals and representative date ranges.
4. Open migrated attachments from the target record that owns them.
5. Run operator tasks from entry through update, correction and reporting.
6. Test a new record, including its generated ID and linked child records.
7. Agree who stops source edits, captures final changes and authorizes the switch.

Define a rollback decision before cutover. Once the new application accepts writes, reopening the old database without reconciling those writes creates competing histories. A rollback plan must say where new records go and who resolves them. The same discipline applies to the broader [data migration](https://remqa.com/data-migration) and any accompanying [application rebuild](https://remqa.com/code-migration).

## How Remqa helps with Access migrations

Remqa can map the data, inspect the surrounding workflow, build repeatable extraction and validation steps, and prepare a controlled application cutover. Bring the database structure and one task your operators depend on. Start with a bounded rehearsal before committing to the full move. Explore our [migration services](https://remqa.com/migrations) to discuss the scope.

## Questions people ask.

**Q: Can PostgreSQL import an Access database file directly with COPY?**
COPY loads supported text, CSV or PostgreSQL binary data into an existing table. It is not an Access database-file converter. Export and transform the data, then create and validate the destination schema.

**Q: Should I export Access data with formatting?**
For a repeatable data migration, unformatted table or query exports are usually the better starting point. Microsoft documents that these include hidden columns and filtered rows from the underlying object and export lookup IDs. Review the scope deliberately.

**Q: Do Access attachments move in a text export?**
No. Microsoft documents that graphical elements, OLE object contents and attachments are not exported to the text file. Extract them separately and keep a link to the original owning record.

**Q: Will Access forms and reports become PostgreSQL screens?**
No. Microsoft provides ways to save object definitions as text, but that is not a translation into a replacement application. Decide which screens and reports to retain, adapt or rebuild, then test their behavior.

**Q: How do I verify an Access to PostgreSQL migration?**
Compare table counts, unique IDs, relationships, numeric totals and representative records. Test nulls, empty text, lookup references, attachments, generated IDs and the real workflows users perform. Explain every rejected or intentionally excluded row.

Book a free 30-minute call with an engineer: https://calendly.com/meghanaj-connect/30min