Share via

Is it possible to use EF data migrations on 2 different machines?

Rod Falanga 956 Reputation points
2026-04-08T03:40:08.6966667+00:00

When doing development, I like to work on both my desktop PC and my laptop PC. I will make changes, commit them to a repo in my GitHub account. Then go to the other machine at a later point, get into PowerShell and do a git pull to get the updated commits.

This works great, almost all the time. The one situation in which I am not as confident in is doing that with Entity Framework Core and data migrations. In this case, I'm using SQLite. The Add-Migration <migration-name> generates the C# class that is used with the Update-Database to create the SQLite database on say my desktop. I'm wondering if I could commit those two steps on my desktop, then go to my laptop, pull the changes down to my laptop, then just run the Update-Database command to create the SQLite database on my laptop?

Developer technologies | .NET | Entity Framework Core
0 comments
Answer accepted by question author
  1. AgaveJoe 31,186 Reputation points
    2026-04-08T10:00:34.8566667+00:00

    Yes, it is absolutely possible. In fact, what you’re describing is the fundamental design and intended workflow of Entity Framework Migrations.

    The migration files generated by Add-Migration are designed to be committed to source control (Git) as part of your codebase. When you pull that code onto another machine, those files provide the instructions necessary for EF to synchronize the local database. This is exactly how teams share schema changes and how CI/CD pipelines deploy database updates to production.

    You can simply pull your changes on the laptop and run Update-Database. EF Core will check the __EFMigrationsHistory table in your local SQLite file, see which migrations haven't been applied yet, and execute them to bring the schema up to date. You can even use the HasData method in your configurations to seed initial data so that your tables are populated automatically on the new machine.

    I highly recommend giving it a try; it’s one of the most powerful features for maintaining environment consistency. You can find more details in the official documentation on Migrations in Team Environments.

    You found this answer helpful.
    0 comments
Answer accepted by question author
  1. Leon Tran (WICLOUD CORPORATION) 1,660 Reputation points Microsoft External Staff Moderator
    2026-04-08T07:53:01.2833333+00:00

    Hi @Rod Falanga

    Thank you for sending us your concern. 

    Yes, this approach can work, and it’s generally how EF Core migrations are expected to be used across multiple machines. 

    When you run <Add Migration>, EF Core generates migration files (the migration class and the model snapshot). These are regular source files, so committing them to your Git repository is fine. Once those files are committed, any machine that pulls the repo has access to the same migration history. 

    On your laptop, after pulling the latest changes, you can run Update Database. EF Core will apply the migrations from the repo and create (or update) a local SQLite database on that machine. Each machine ends up with its own database file, but the schema stays consistent because it’s based on the same migrations. 

    A few things to keep in mind: 

    You generally don’t want to commit the SQLite database file itself, since it’s machine specific. 

    Make sure all migration files and the snapshot are committed together. 

    Avoid making schema changes directly in the database outside of migrations. 

    With that setup, your workflow of creating migrations on one machine, committing them, then applying them on another machine should be fine in most cases, including when using SQLite. 

    Hope this helps! If my answer was helpful, please consider marking it so others with the same issue can benefit as well. You can follow this guidance to see how to do it.  

    0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Q&A Assist
    2026-04-08T03:40:22.0966667+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    Yes, this is supported and is a common way to work.

    Key points for the workflow described:

    1. Add the migration on one machine
      • Change the EF Core model.
      • Run Add-Migration <Name> on (for example) the desktop.
      • Optionally run Update-Database there to update/create the local SQLite database.
      • Commit the migration files (including the model snapshot) to source control.
    2. Pull the changes on the other machine
      • On the laptop, run git pull to get the updated code and migration files.
      • Run Update-Database against the local SQLite database.
      • EF Core uses the checked-in migration files and the __EFMigrationsHistory table in the local database to determine what needs to be applied.
    3. Why this works
      • Migrations are just C# code files plus a model snapshot that are designed to be shared via source control and applied on different databases/environments.
      • Each machine has its own local database and its own migrations history table, so they do not interfere with each other.
    4. SQLite-specific note
      • SQLite has some limitations around certain schema operations and idempotent scripts, but applying normal EF Core migrations via Update-Database on each machine is supported as long as the operations in the migrations are supported by SQLite.

    As long as all migrations are committed and both machines always pull the latest changes before adding new migrations, running Update-Database on each machine to create or update the local SQLite database is the correct approach.

    References:

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.