If your .NET project relies on AutoMapper and you're starting to feel the pain of implicit mapping, runtime surprises, or costly allocations, it’s time to consider migrating to Moedim.Mapper. Moedim.Mapper gives you explicit, maintainable mappings with modern .NET patterns — and it ships with tooling to make migration from AutoMapper straightforward.
This post explains why teams choose Moedim.Mapper, how it differs from AutoMapper, and provides a step‑by‑step migration walkthrough (including examples and migration tooling tips) so you can move confidently.
Repository: https://github.com/kdcllc/Moedim.Mapper
TL;DR
Moedim.Mapper focuses on explicit, clear mapping code that’s easy to reason about and debug.
It reduces runtime surprises by favoring compile‑time safety and more direct code generation patterns.
The project includes migration tooling that helps convert AutoMapper Profiles into Moedim mapping code scaffolds.
This post gives quick before/after examples and a migration checklist so you can plan the transition.
Why migrate? Pain points with AutoMapper
Implicit mapping: AutoMapper’s convention-based mapping is convenient but can hide logic. When mappings come from conventions or profiles spread across the codebase, diagnosing unexpected values becomes harder.
Runtime surprises: Missing mappings or configuration mistakes often result in runtime behavior that can be subtle to track down.
Debugging: Tracing mapping logic in generated expression trees is difficult for many developers.
Performance: Depending on usage patterns, reflection and expression trees can add overhead (especially for high-throughput scenarios).
What Moedim.Mapper brings
Explicit mapping definitions that are readable and easy to debug.
A smaller mental model — mappings are explicit code rather than implicit conventions.
Tooling to help convert existing AutoMapper Profiles into Moedim mapping code.
Better productivity for teams that prefer to keep mapping logic visible and testable alongside the rest of the code.
Quick comparison (conceptual)
AutoMapper: Convention + Profiles -> runtime expression tree / reflection mapping
Moedim.Mapper: Explicit definitions (and/or source-generated code) -> direct, readable mapping code
Quickstart — examples
- Example AutoMapper Profile (before)
using AutoMapper;
public class CustomerProfile : Profile
{
public CustomerProfile()
{
CreateMap<CustomerEntity, CustomerDto>()
.ForMember(d => d.FullName, opt => opt.MapFrom(s => s.FirstName + " " + s.LastName))
.ForMember(d => d.IsActive, opt => opt.MapFrom(s => s.Status == Status.Active));
}
}
- Equivalent mapping with Moedim.Mapper (after)
- Moedim.Mapper favors explicit converters/mappers which you can place next to your DTOs or in a dedicated mappings folder:
public class CustomerMapper : IMapper<CustomerEntity, CustomerDto>
{
public CustomerDto Map(CustomerEntity s)
{
if (s == null) return null;
return new CustomerDto
{
Id = s.Id,
FullName = $"{s.FirstName} {s.LastName}",
Email = s.Email,
IsActive = s.Status == Status.Active
};
}
}
- Registering mappings with DI
- With AutoMapper you typically add profiles:
services.AddAutoMapper(typeof(CustomerProfile).Assembly);
- With Moedim.Mapper, registration is explicit and usually just registering mappers or allowing convention-based scanning:
services.AddScoped<IMapper<CustomerEntity, CustomerDto>, CustomerMapper>();
services.AddMoedimMappers(typeof(CustomerMapper).Assembly);
Migration tool — make the move faster One reason teams delay migration is the perceived cost of rewriting all mapping profiles. To help, Moedim.Mapper includes migration tooling in the repository that:
Scans AutoMapper Profile classes (and/or scans compiled assemblies)
Generates scaffolded mapping classes that follow Moedim.Mapper patterns
Preserves custom MapFrom expressions as inline assignments when possible
Emits TODO comments when conversion is ambiguous so you can inspect and finalize migration
Example (high level) CLI usage
- Scan your project and emit scaffolded mappers to a folder (the exact CLI and arguments are in the repository's tools folder; adjust to what your checkout provides):
# hypothetical example — check the repo for exact CLI usage
dotnet tool run moedim-migrator --source ./MyProject --out ./GeneratedMappers
What the migrator does for the earlier example
Converts CreateMap/ForMember MapFrom expressions into explicit assignments.
For complex expressions that use external methods or value resolvers, the migrator emits equivalent inline code or a TODO to implement a helper.
After running the migrator you'll get a set of ready-to-review mapping classes you can include in your project and refine.
Step-by-step migration plan
Add Moedim.Mapper to your solution
Run the migration tool against the assembly that contains your AutoMapper profiles
- Review generated files in GeneratedMappers (or whichever output folder you chose)
Add the generated mappers to your project and compile
- Fix any TODOs the migrator emitted (these are places where manual attention is required)
Register mappers in DI (either manually or using a provided scanning helper)
Run your unit tests to verify behavior
Remove AutoMapper package and profiles once everything is validated
Practical tips and patterns
Migrate incrementally: Start with a bounded area (e.g., a feature or microservice). Migrate only the mappings touched by that feature.
Keep tests: If you have unit or integration tests that validate mapping output, keep them in place — they will provide quick feedback that the migration preserved behavior.
Use the generated scaffolds as a starting point — hand-tune complex mappings to be idiomatic and efficient.
Embrace explicitness: Where AutoMapper used magic and conventions, Moedim.Mapper asks you to be intentional. This pays off in maintainability.
Advanced scenarios
Collection mappings: Most mappers need to handle IEnumerable -> List etc. Moedim.Mapper provides helpers (or simple loops) for these conversions. The migration tooling will scaffold collection conversions when it detects them.
Projection and IQueryable: If you relied on AutoMapper’s ProjectTo for EF Core projections, check Moedim.Mapper documentation for pattern alternatives (explicit projections or expression-based projections) and migrate gradually.
Conditional mapping: Translate AutoMapper Condition/PreCondition to explicit guards in the mapping method.
Testing and verification
Keep your mapping tests. For each migrated mapping, add a unit test that creates a source object and asserts the target object properties.
Add test coverage around corner cases (nulls, empty lists, special enums) — the explicit mapping code makes it easier to reason about and test those edge cases.
Performance, debugging, and maintenance
With explicit mapping code you can step through mapping logic in your debugger easily. This reduces time-to-diagnose when values are wrong.
The generated mapping code tends to be straightforward and optimized by the runtime; you eliminate hidden expression tree building or reflection at runtime in many cases.
Explicit mappings are easier to profile and inline small optimizations when they matter.
FAQ Q: Will I lose productivity without AutoMapper’s conventions? A: You will lose some of the automatic "magic", but you gain predictability and explicit control. The migration tooling helps narrow the work by scaffolding the bulk of classes; from there, refining is usually minimal.
Q: Can I keep AutoMapper and Moedim.Mapper side-by-side during migration? A: Yes. Migrate mappings incrementally, and keep both libraries until you’ve validated parity. The migration plan above is designed for incremental transitions.
Q: Does Moedim.Mapper support the same advanced features as AutoMapper (value resolvers, converters, projection)? A: Moedim.Mapper focuses on clear and explicit mapping primitives. For advanced scenarios you typically implement small helper methods or converters; these are explicit and directly testable. Check the repository for guides and examples.
Call to action
Try the migration on a small feature first. Run the migrator, review the output, and keep tests green.
Browse the repo: https://github.com/kdcllc/Moedim.Mapper
If you find missing scenarios or want smoother migration for your codebase patterns, open an issue or contribute a PR — your real-world mappings improve the tooling for everyone.
Closing Migrating from AutoMapper to Moedim.Mapper is about trading some of AutoMapper’s convenience for clearer, debuggable, and maintainable mapping code. With provided migration tooling and a small, sensible plan, you can reduce runtime surprises, simplify debugging, and make mapping logic part of your application's readable, testable codebase.
Happy mapping — and if you'd like, I can:
generate example migration output for one of your Profile classes,
produce a checklist specific to your repo structure,
or draft a PR to integrate generated mappers into your project. Just tell me which Profile (or file path) to convert.
