6 microservices folded into 1 container, with not one record of legacy data lost
A vocational education group
What it looked like before
The original learning platform was split into 6 microservices calling each other over HTTP with URL-based configuration. One version upgrade meant coordinating 6 repositories and a dozen-odd containers — expensive to operate and hard to troubleshoot. Meanwhile the system had accumulated a large body of historical course and learner data, and the business was explicit: no rebuilding from scratch.
What we delivered
Rebuilt as Unilearning’s modular monolith: 8 business domains aggregated in-process, recognising only api contracts between domains, with the internal wall enforced by the compiler. The legacy-import tool migrated the old database and the old identity database with all IDs preserved, so existing users could log in directly with their original bcrypt passwords.
- The modular monolith turns service-to-service calls back into in-process function calls; troubleshooting shifts from cross-service tracing to single-process logs
- The uv1 / tv1 / admv1 route paths stay compatible with the old front ends — not one line of front-end code changed
- Migration proceeded domain by domain, each domain with its own set of versioned migration files and independently rollback-able
- Existing users keep their original passwords with no forced reset, and support ticket volume did not rise
What we feared most was learners failing to log in on migration day. Not one anomaly was reported, and the contingency plan we had prepared was never used once.
Hand the complexity of identity, agents and private domain to one governable kernel
Whether you are replacing an existing IAM, building an agent platform, or trying to make private-domain operations actually work — start with a 30-minute architecture call. We will first judge whether this is the kind of problem we are good at, and say so plainly if it is not.