Moving From Express to Standard Without Reinstalling

You can upgrade SQL Server edition from Express to Standard through Setup when the release supports that path. The instance stays in place, but the change still needs a backup, a maintenance window, and a tested recovery plan.

Confirm the Path Before Opening Setup

An edition upgrade changes the feature and capacity level of an installed instance. A version upgrade changes the SQL Server release. Those are related decisions, but they aren’t interchangeable. Start by recording exactly what is installed and exactly what you intend to install.

SELECT
    @@SERVERNAME AS server_name,
    SERVERPROPERTY('InstanceName') AS instance_name,
    SERVERPROPERTY('Edition') AS edition,
    SERVERPROPERTY('ProductVersion') AS product_version;

Use Microsoft’s supported version and edition upgrade matrix for that source and destination. Check the operating system and installed components too. A supported Express-to-Standard path doesn’t promise that every combination of old media, build, and Windows release will work.

Get the appropriate licensed Standard media and product key before scheduling downtime. Developer media isn’t a substitute for production licensing. A major-release change adds compatibility work. Include that work in the plan rather than treating it as a bonus click.

Capture More Than the User Databases

Back up every user database and the relevant system databases. Save configuration values, service account details, and application connection settings. Script logins and anything needed to rebuild the environment. A database backup alone doesn’t recreate the Windows service or its permissions.

SELECT
    name, state_desc, recovery_model_desc,
    compatibility_level, collation_name
FROM sys.databases
ORDER BY database_id;

Check that your backups can be restored on a separate test instance. Keep that instance at a compatible version. A successful backup job isn’t a restore test. Record the restore procedure and the location of credentials needed to read encrypted backup files.

If you use Windows authentication, include the service account’s access to backup and data locations. Changing edition shouldn’t require moving those files, but recovery could. Avoid discovering missing permissions after the original service is unavailable.

Keep a Before Copy of Configuration

SELECT
    name, value, value_in_use, is_dynamic
FROM sys.configurations
ORDER BY name;

Save the result outside the instance you are changing. It is useful for comparing settings afterward and rebuilding elsewhere. Also record file locations and current sizes. Setup logs help explain installation failures, but they aren’t a substitute for your own before-state record.

I would rehearse this on a restored copy if the application is important. That rehearsal tests assumptions about drivers and logins as well as Setup. It also gives you a basis for the maintenance window. Don’t turn someone else’s installation time into your outage estimate.

Run the Edition Upgrade Deliberately

Open SQL Server Installation Center from the appropriate installation media. Under Maintenance, choose Edition Upgrade. Select the existing Express instance and follow the validation rules. Read each reported issue rather than assuming a warning is harmless because the Next button is available.

Stop application activity as planned and account for service interruption. Setup changes installed components and can restart services. Confirm the selected instance again before applying the change. A server with several instances provides several opportunities to upgrade the wrong one.

The supported in-place route keeps the instance identity and its databases. You shouldn’t need to export and reimport every table. Keep the application connection target unchanged unless your tested plan requires something else. Review the Setup summary and detailed logs before declaring the installation complete.

Check the Engine and Then the Application

SELECT
    SERVERPROPERTY('Edition') AS edition_after,
    SERVERPROPERTY('ProductVersion') AS version_after;

SELECT name, state_desc
FROM sys.databases
WHERE state_desc <> 'ONLINE';

Confirm the expected edition and build, then compare your saved inventory. Check services, authentication, and the error log. Run representative application operations using its normal account. A successful administrator connection proves less than a successful application transaction.

Standard adds capabilities that Express lacks, including SQL Server Agent. Verify any new Agent service and job configuration separately. The upgrade doesn’t invent a sensible backup schedule for you. Keep existing external schedules until their tested replacements are ready, avoiding duplicate backup or maintenance jobs.

Know What Going Back Means

Setup doesn’t provide a general in-place edition downgrade button. Returning to Express usually means preparing another instance and migrating compatible databases. Features introduced after the upgrade can make that return harder. The Express size limit still applies when you try to move back.

Decide how you will recover before starting, including what happens to writes made after reopening the application. Restoring an old backup discards later changes unless you have a tested recovery path. Keep the old evidence and backups until the new environment has passed your agreed checks.

An edition upgrade is not a new database, it is a change to the engine that deserves a recovery plan.

This post was rewritten from scratch in September 2026. The original, published on 2017-12-22, was a short announcement about something that no longer exists. The address is the same, the subject is now something worth keeping.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.