“Upsizing” is the term for moving Access database tables from the local .accdb file to a server database like SQL Server while keeping the Access application as the front-end. The term dates back to when Microsoft included an Upsizing Wizard directly in Access.

If someone tells you to “upsize your database,” this is what they mean: move the data, keep the application.

How Upsizing Works

The process has three phases:

Phase 1: Create the server database. A new, empty database is created on the target server. The table structures from your Access database are recreated using the server’s data types and constraints.

Phase 2: Transfer the data. The rows from your Access tables are inserted into the corresponding server tables. Primary keys, indexes, and relationships are recreated on the server.

Phase 3: Re-link the Access front-end. The original Access tables are deleted or renamed, and linked tables are created that point to the server tables. Forms, reports, and queries now operate against the server data through ODBC.

After upsizing, your Access application looks and works the same from the user’s perspective. The data just lives somewhere better.

The Built-In Upsizing Wizard

Older versions of Access (2003 and earlier) included an Upsizing Wizard that automated this process for SQL Server. You selected your tables, pointed it at a SQL Server instance, and it handled the conversion.

The current status: The Upsizing Wizard has been removed from modern versions of Access. If you are using Access 2010 or later, it is not available. Microsoft replaced it with the SQL Server Migration Assistant (SSMA), which is a separate free download.

If you find online tutorials referencing the Upsizing Wizard, they are outdated. Do not spend time looking for it in your current version of Access.

SQL Server Migration Assistant (SSMA)

SSMA is Microsoft’s current tool for migrating Access databases to SQL Server. It is free, actively maintained, and significantly more capable than the old Upsizing Wizard.

What SSMA does: - Analyzes your Access database and generates a migration report - Converts Access table structures to SQL Server equivalents - Maps Access data types to SQL Server data types - Transfers data from Access tables to SQL Server - Identifies queries and VBA code that may need modification - Generates a conversion report showing what succeeded and what needs manual attention

What SSMA does not do: - Convert your forms or reports - Rewrite your VBA code - Set up ODBC linked tables in Access - Fix data quality issues in your source database - Handle Access-specific features like multi-value fields or attachment fields

How to use it: 1. Download SSMA for Access from Microsoft (free) 2. Install it on a machine that can reach both the Access file and the SQL Server instance 3. Create a new migration project 4. Connect to your Access database 5. Connect to your SQL Server instance 6. Select the tables to migrate 7. Review the conversion report 8. Execute the migration 9. Manually set up ODBC linked tables in your Access front-end

When SSMA Works Well

SSMA handles straightforward migrations well: - Tables with standard data types (Text, Number, Date/Time, Yes/No, AutoNumber) - Simple relationships (one-to-many with referential integrity) - Standard indexes - Moderate data volumes (under 1GB)

If your database is a clean, well-designed relational database, SSMA can complete the table migration with minimal manual intervention.

When SSMA Struggles

SSMA has difficulty with:

Complex queries. SSMA will attempt to convert Access queries to SQL Server views, but complex queries with Access-specific functions, subqueries, or crosstab designs often fail to convert. You will need to rewrite these manually.

Multi-value and attachment fields. These Access-specific field types have no SQL Server equivalent. SSMA cannot convert them. You need to restructure these fields before migration.

Poorly designed schemas. If your Access database has no primary keys, circular relationships, or tables that serve as both data storage and lookup lists, SSMA will flag these issues but cannot fix them.

Large databases. For databases approaching the 2GB limit, the data transfer phase can be slow and may time out. Breaking the migration into batches (migrating a few tables at a time) helps.

Complex VBA. SSMA can scan VBA code and flag statements that reference Access-specific objects, but it cannot rewrite the code. This is manual work.

Manual Upsizing (Without SSMA)

For non-SQL Server targets (MySQL, MariaDB, PostgreSQL), or if you want more control over the process, you can upsize manually:

  1. Create the target database on the server using the server’s management tool
  2. Create the tables manually, mapping Access data types to the server’s types
  3. Export data from Access using INSERT statements, CSV export, or a migration script
  4. Import data into the server using the server’s import tools
  5. Create indexes and constraints on the server tables
  6. Set up ODBC connections on each workstation
  7. Create linked tables in Access pointing to the server tables
  8. Test everything

This approach gives you complete control over data type mapping, naming conventions, and table design. It is more work than using SSMA but produces cleaner results for databases with complex schemas.

The ODBC Linked Table Setup

After the data is on the server, you need to link the Access front-end to the server tables. This is the same regardless of which migration method you used:

  1. In Access, go to External Data > ODBC Database
  2. Select “Link to the data source by creating a linked table”
  3. Choose your ODBC data source (or create a new one)
  4. Select the tables to link
  5. For each table, select the primary key columns when prompted

After linking, your forms and queries that referenced the original Access tables now need to reference the linked tables. If the table names are the same, this happens automatically. If you renamed tables during migration, you will need to update references.

Should You Split the Database First?

If your Access database is not already split (front-end/back-end), split it before upsizing. The Database Splitter wizard (Database Tools > Access Database) separates your tables into a back-end file and your forms/code into a front-end file.

Why split first: - It verifies that your application works with linked tables before you add the complexity of ODBC - It identifies forms and queries that depend on local table behavior - It gives each user their own front-end file, which is needed for the final architecture

The Recommendation

For SQL Server targets, use SSMA. It is free, it is Microsoft’s supported tool, and it handles the routine parts of migration automatically. Plan to spend time on the issues SSMA flags but cannot fix — those are the parts that need your knowledge of the application.

For MySQL, MariaDB, or PostgreSQL targets, use manual upsizing or a third-party migration tool. The process is more hands-on but gives you better control over the result.

Either way, the actual data migration is the straightforward part. The real work — testing forms, fixing queries, adjusting VBA code — comes after the tables are moved. Plan your timeline accordingly.