Application Processing Platform
The problem
Meridian handles around 2,400 immigration applications a year. When we met them, each one lived in three places at once: a shared inbox where clients sent documents, a folder structure on a network drive, and a master spreadsheet that one person maintained and everyone else was slightly afraid of.
Nothing was broken exactly. But answering "where is my application?" took a caseworker four to six minutes of clicking, and the answer was sometimes wrong. Two staff had effectively become routers, moving files and chasing missing documents rather than doing case work.
The trigger was a regulatory audit. They could not produce a reliable history of who changed what, and when.
Constraints we designed around
No downtime
Data residency
Nine years of history
Architecture
A single ASP.NET Core application with a React front end, backed by SQL Server. We deliberately did not build microservices — with four engineers and one deployment target, the coordination cost would have outweighed anything we gained.
Documents sit in blob storage with signed, expiring URLs; the database holds only references and extracted metadata. Every state change writes to an append-only audit table, which is what satisfied the auditors.
Outcome
What we'd do differently
We under-scoped the migration by about three weeks. We treated nine years of records as a data problem when it was really a decisions problem — someone had to rule on what a duplicate was, and that person had a day job. Next time we start migration discovery in week one, not week eight.
Need a system like this?
We'll map your process against this architecture and tell you what changes.