Sample Database Migration Plan for EF-Core to FluentMigrator

 Executive Summary

A monolithic web solution (“MainWeb”) and a companion service (“Jobs.Api”) both use Entity Framework Core (EF Core) migrations against a shared PostgreSQL database. Maintaining duplicate entity definitions and migrations across two projects is inefficient—especially because Jobs.Api intends to drop EF Core altogether. This proposal outlines migrating both codebases to FluentMigrator, a framework-agnostic migration tool. A dedicated migration project will become the single source of truth, while Jobs.Api moves to Dapper for data access and MainWeb keeps EF Core strictly for querying. The approach streamlines schema management and supports an eventual move away from a monolith.

---

Current Situation

Component	Status
MainWeb (Monolith)	Uses EF Core for data access and migrations; migration history lives in __EFMigrationsHistory.
Jobs.Api	Shares database objects with MainWeb; currently EF Core-based but aiming to remove that dependency.
Shared Database	One PostgreSQL instance managed by MainWeb’s EF Core migrations, requiring tight coordination.

---

Challenges

• Duplication — Entities exist in two codebases, creating redundant work.

• Migration Coordination — Two different data-access strategies must agree on each schema change.

• EF Core Dependency — Jobs.Api’s desire to drop EF Core is blocked by MainWeb’s migration workflow.

• Monolith Constraints — MainWeb’s size makes a full rewrite impractical in the short term.

---

Proposed Solution

Pillar	Details
Central Migration Project	Create Database.Migrations, powered by FluentMigrator. It owns every schema change.
Jobs.Api Transition	Remove EF Core, adopt Dapper, and apply migrations via the shared FluentMigrator project.
MainWeb Adaptation	Keep EF Core for querying, but stop using EF Core migrations. After each FluentMigrator run, manually synchronize the EF Core model.
Long-Term Path	Gradually refactor MainWeb into smaller services that also use FluentMigrator and lightweight data-access libraries.

---

Implementation Plan

Step	Objective	Key Actions
1. Create Database.Migrations	Centralize schema changes	- Add FluentMigrator & Runner. - Configure Postgres provider and VersionInfo table. - Add an InitialMigration that marks today’s schema as baseline.
2. Transition Jobs.Api	Eliminate EF Core	- Remove EF Core packages. - Add Dapper. - Apply migrations on startup via the Runner.
3. Adapt MainWeb	Keep EF Core for data access only	- Disable context.Database.Migrate() calls. - Reference Database.Migrations. - Update entities/DbContext after each migration.
4. Coordinate Schema Changes	Prevent drift	- Author new migrations in Database.Migrations. - CI/CD applies them. - Jobs.Api auto-updates; MainWeb updates its model manually.
5. Preserve Existing EF Core History	Avoid disruption	- Keep __EFMigrationsHistory as-is. - Treat the initial FluentMigrator baseline as authoritative going forward.

---

Benefits

• Single Source of Truth — One migration pipeline eliminates drift.

• Flexibility for Jobs.Api — Dapper + FluentMigrator removes heavyweight ORM overhead.

• Future-Proofing — Aligns with a gradual break-up of the monolith.

• Version Control Friendly — FluentMigrator’s C# migrations are easy to review in Git.

---

Risks & Mitigations

Risk	Mitigation
Manual EF Core model updates may lag	Document the process; add validation tests to catch mismatches.
Extra coordination overhead	Define a clear “write-migration-first” workflow and automate via CI/CD.
Learning curve for FluentMigrator	Provide quick-start guides and internal training sessions.
Long-term MainWeb refactor effort	Plan phased service extraction to spread effort over time.

---

Timeline (Indicative)

Phase	Tasks	Duration
Setup Migration Project	Create Database.Migrations, configure baseline	1–2 weeks
Transition Jobs.Api	Remove EF Core, add Dapper, wire up migrations	2–3 weeks
Adapt MainWeb	Disable EF Core migrations, document model-sync steps	1–2 weeks
Process & CI/CD	Formalize workflow, automate migration execution	1 week
Long-Term Refactor	Gradual decomposition of the monolith	Ongoing

---

Conclusion

Moving to FluentMigrator centralizes database evolution, lets Jobs.Api shed EF Core, and positions the system for a future microservice architecture. By balancing short-term practicality with long-term flexibility, this plan reduces duplication, lowers maintenance overhead, and creates a clear, auditable history of schema changes.

Checkout my FluentRun project on Github. It is a FluentMigrator tool that runs seamlessly with any .net project: https://github.com/DotNetDeveloperDan/FluentRun