Moving A LocalDB Instance To A Newer SQL Server Version

An mssqllocaldb move instance task is really a rebuild. You stop the running instance, back up the databases, delete the old instance, create a new one on the target version, and attach the data files again. Nothing in LocalDB relocates an instance in one step, so the files you keep are what actually travel.

SQL Server Express LocalDB is a lightweight mode of the Express edition for developers who want to write and test Transact-SQL code without a full server instance or complex configuration tasks. A LocalDB installation adds a minimal set of files, and the SQL Server Database Engine is automatically created and started the first time a connection string points at it. Current releases are 16.x (SQL Server 2022) and 17.x (SQL Server 2025). They arrive through Advanced Services media, a standalone package, or Developer Tools, and none of them depends on existing SQL Server infrastructure.

mssqllocaldb move instance

Relocating a LocalDB instance between versions is a delete-and-recreate job, because the instance is tied to the engine build that created it while the data files are portable. Many people hunt for a hidden upgrade switch, but practitioners who maintain developer machines treat the instance as disposable and the databases as the real asset.

Upgrade To The Latest Version / Switching From An Old To A Newer Version

To switch from an old version to a newer version, stop the instance, back up the databases, delete the current instance, create a new instance on the latest version available, and re-attach the data files. The SqlLocalDB.exe utility has no upgrading verb, so delete and re-create instances is the supported route.

Read The Instance Before Touching It

Run sqllocaldb info MSSQLLocalDB. The output lists Name, Version, Shared name, Owner, Auto-create, State, Last start time and Instance pipe name. A Version such as 13.1.4001.0 or 15.0.2000.5 shows which generation you are on, and the second is LocalDB 2019 at its original build. A State of Running means a running instance is still holding its files, so close all application windows that use it, SSMS and other Tools included.

Each version keeps its binaries in a numbered folder, for example …\150\LocalDB\Binn for LocalDB 2019. The sqllocaldb on your path may therefore not be the copy for the version you want.

The Sequence That Works

1. Back up first. Copy the .mdf and .ldf files or take a regular backup of the databases. Caution: deleting an instance means you lose the mapping between it and its databases. Files in your own folders survive, but anything stored in the instance folder is removed.
2. Stop the instance with sqllocaldb stop MSSQLLocalDB.
3. Remove it with sqllocaldb delete MSSQLLocalDB.
4. Bring it back. With the default name deleted, the next connection normally triggers Auto-create, and the instance returns under the same name on the newest installed version. For explicit control, run sqllocaldb create DevInstance17 17.0, but then every connection string must change.
5. Start and attach. Run sqllocaldb start MSSQLLocalDB, then use Attach in SSMS (or CREATE DATABASE … FOR ATTACH) for each database.

Attaching is one-way. Once the newer engine opens a database, the files can’t return to the older version, and compatibility level stays at its previous value until you raise it deliberately.

Practitioners often note that keeping the default name matters more than expected. Connection strings reading (localdb)\mssqllocaldb keep working untouched. If the old instance was shared, set sharing again, because the Shared name died with it. The usual motive for the whole exercise is stability and known fixes in newer builds. SQL Server Express ships the same LocalDB, so the procedure is identical wherever it came from.

Create And Connect To A Named Instance / Creating An Instance With A Specific Version

To create an instance on a specific version, list the installed LocalDB versions with sqllocaldb versions, run sqllocaldb create mssqllocaldb2025 17.0, and connect to (localdb)\mssqllocaldb2025. The SqlLocalDB utility treats any name outside the reserved automatic pattern as one of the named instances.

sqllocaldb versions

sqllocaldb create mssqllocaldb2025 17.0

sqllocaldb start mssqllocaldb2025

sqllocaldb info mssqllocaldb2025

The versions output pairs each release with a build, such as SQL Server 2019 with 15.0.4382.1 or SQL Server 2025 with 17.0.925.4. If SQL Server 2022 is the target, the matching Binn folder is numbered 160 and the version argument is 16.0.

What The Info Output Tells You

Connecting From Tools And Code

In SQL Server Management Studio, open the Connect to Database Engine dialog and type (localdb)\mssqllocaldb2025 into Server name. If the alias misbehaves, paste the Instance pipe name instead. The LOCALDB# portion changes with each start, so copy it fresh.

A custom program needs .NET Framework 4.0.2 or later. Its SqlConnection can use Server=(localdb)\LocalDBApp1;Integrated Security=true;, which runs as the Windows user. When finished, sqllocaldb stop LocalDBApp1 releases the files.

Installation Media

LocalDB installs from SqlLocalDB.msi. You get it from the SQL Server Express download media, as a standalone LocalDB package, or as an individual component in Visual Studio Installer. In the Express edition installer, choose Download media, pick LocalDB (Express Core and Express Advanced are the larger siblings), select the language and x64, and save the files.

Inside the unpacked media, installation_media_root typically holds a language folder such as 1033_ENU_LP. Here 1033 is the LCID, the locale identifier for en-US, and ENU_LP is the language code with its pack. The msi usually sits under x64\Setup.

Visual Studio’s ASP.NET and web development workload and its Data Storage and Processing workload both offer LocalDB as an individual component. Build agents are better served by the msi alone, because a full SQL Server Express installation brings far more than they need.

Install LocalDB

Install LocalDB by running SqlLocalDB.msi, or by selecting it on the Feature Selection/Shared Features page of the installation wizard. Either route lays down the same binaries as SQL Server Express and the SqlLocalDB.exe utility.

One installation of the binary files serves every Database Engine process of that major version, and each user’s instances run as their own processes. A 16.x and a 17.x therefore coexist, because the Database Engine version of an instance is fixed to the major version that created it. LocalDB replaced the SQL Server Express user instance feature, which is deprecated. Its limitations come up shortly.

Description

A LocalDB instance keeps its system database files in a hidden AppData folder under the user’s profile. Its instance collation is SQL_Latin1_General_CP1_CI_AS, and it can’t be changed. The Instances folder normally sits at %LOCALAPPDATA%\Microsoft\Microsoft SQL Server Local DB\Instances\<InstanceName> and holds master, model, msdb and tempdb. User database files stay wherever they were attached.

How Collation Plays Out

The fixed instance collation governs tempdb and instance-level metadata. Database-level, column-level and expression-level settings can still differ, and mismatches are the classic source of comparison errors involving temporary tables. Practitioners often favor contained databases here, since their metadata and temporary objects follow the database’s own collation, which is helpful during a move. Collations rules are the first thing to check when a restored database behaves oddly on a new instance.

Who Manages It

The SqlLocalDB utility and the LocalDB API manage instances, and SqlLocalDB.msi installs the engine bits derived from SQL Server Express. Visual Studio’s Local Data Overview documentation covers the developer-side workflow, and project-specific instances such as LocalDBApp1 are common there.

Restrictions

LocalDB can’t be reached remotely, doesn’t support FILESTREAM, handles Service Broker only with local queues, and can act as a merge replication subscriber only. These limits follow from its lightweight, per-user design.

The owner should be a normal Windows account. Instances owned by built-in accounts such as NT AUTHORITY\SYSTEM run into manageability issues, largely because of Windows file system redirection. SQL Server Management Studio connects without trouble, but only from the same computer. Services running under built-in accounts are where practitioners most often see this go wrong.

Automatic And Named Instances

LocalDB supports two instance types, automatic and named, and each runs in its own process under the respective user that owns it. Instances are per user on a computer, so the same name can exist for different users without collision. Two developers on a shared build box each get a private instance with identical names.

Automatic Instances

An automatic instance is a public instance that is created and managed automatically, so any application can use it without anyone running a create command. The name MSSQLLocalDB lives in a reserved namespace, which avoids name conflicts with named instances.

Why Applications Like Them

• There is no need to create anything during application installation, and the target machine needs no preparation.
• One automatic instance exists for every version of LocalDB on the user’s computer.
• The instance name follows a special pattern. Older generations used version-based names such as v11.0, while recent ones use MSSQLLocalDB.
• An app asks for the specified version and gets it, which gives seamless instance management and makes migration to a newer release a configuration matter.

Named Instances

A named instance is private and owned by a single application, and it is created explicitly through the LocalDB management API or implicitly by a managed application that reads app.config. It gives isolation, and it can improve performance by cutting resource contention with other database users.

Names are sysname values of up to 128 characters, may include Unicode characters, and must work as a filename. NetBIOS names are limited to 15 ASCII characters, so short plain ASCII names behave best with older tools. Regular named instances can’t borrow an automatic instance name. Each one picks a LocalDB version and shares that version’s binaries.

Shared Instances Of LocalDB

A shared instance is a LocalDB instance whose owner exposes it to multiple users under a unique shared name, an alias visible to all users on the computer. Instance sharing is off by default, so an instance stays unshared until the owner or an administrator changes that.

There are two methods. The LocalDB API offers LocalDBShareInstance and LocalDBUnShareInstance, and the SqlLocalDB utility offers share and unshare options:

sqllocaldb share LocalDBApp1 TeamDb

sqllocaldb unshare TeamDb

Sharing typically needs administrator rights. The shared name uses the same format as any named instance. The instance owner’s account still runs the process. Sharing is normally applied to a named instance, since an automatic instance is only public to its own user’s applications.

Start LocalDB And Connect To LocalDB

LocalDB starts on demand. Connect to an automatic instance, a named instance, or a shared instance, and a stopped engine launches itself. The three differ only in the server string: (LocalDB)\MSSQLLocalDB, (LocalDB)\<name>, and (LocalDB)\.\<sharedname>.

Connect To The Automatic Instance

Connect with Server=(LocalDB)\MSSQLLocalDB;Integrated Security=true, which authenticates as the current user. The first time through, the instance is created and started, and that connection attempt can outlast the default timeout. If a timeout message appears, wait a few seconds and connect again.

To open a specific database, add AttachDbFileName with the file name:

Server=(LocalDB)\MSSQLLocalDB;Integrated Security=true;AttachDbFileName=D:\Data\MyDB1.mdf

Raising the timeout inside the connection string is a common fix on slower disks.

Connect To A Shared Instance Of LocalDB

Connect to a shared instance by adding a backslash and a dot after the namespace, for example Server=(localdb)\.\AppData, where AppData is the shared name and has nothing to do with the folder. The dot tells LocalDB to look in the shared set rather than the caller’s private instances, and the (localdb) namespace is reserved for this purpose.

Windows Authentication works for users the owner has allowed. SQL Server Authentication works only if a login exists. A user who doesn’t own the instance can’t create that login, so the owner must set it up.

Troubleshoot 

Most LocalDB problems trace back to instance state, version mismatches, file permissions, or the user’s context, and the quickest way to diagnose them is to check the instance and then read its log. Because it is a lightweight instance, server-level configuration is minimal, so you can usually resolve common LocalDB problems without touching anything beyond the instance itself.

Verify The Installation And Instance Status

Run sqllocaldb info. If it lists instances such as MSSQLLocalDB with a State of Running, the installation and the instance are healthy. If the command is not recognized, the PATH variable is missing the installation path of the LocalDB Binn folder, so add it system-wide.

For a single instance, sqllocaldb info MSSQLLocalDB shows the owner, state and version. A Stopped state is fixed by sqllocaldb start MSSQLLocalDB, which is also how you start an instance deliberately.

Review Error Logs

Open error.log, found under %LOCALAPPDATA%\Microsoft\Microsoft SQL Server Local DB\Instances\MSSQLLocalDB, in any text editor. The error logs record error messages for startup failures and configuration problems. AppData is hidden by default, so paste the full path instead of browsing to it.

Permissions

A LocalDB instance runs in the security context of its owner’s Windows account, so database files must sit where that account has file system access, and the user profile is the safe default. Installing needs administrators, but running does not. Membership in the local Administrators group isn’t required to use an instance, and connections use the owner’s Windows credentials.

A protected location such as Program Files rejects writes from a normal account. A shared location, such as a network folder, adds permission and locking trouble, so the user’s data folder is the better home for database files. A database file can be attached to one instance at a time, which is why the old instance must be stopped before a move. This is the same for every SQL Server Express LocalDB version.