mmitech
Own-brand build Visit live site ↗

Last updated

Hero image for the Mmi Services case study

MMI Services - taking over and modernising a 2008-era claims platform without breaking what still works

A live-production legacy-modernisation engagement on the studio’s own sister brand: a 2008-era line-of-business claims-handling system that still runs the business, sat behind a modern marketing surface, with the legacy pages systematically de-risked, performance-tuned, and modernised in place rather than rewritten from scratch. The reference build for “we can take over what you’ve got and modernise it without forcing a rewrite that breaks the business”.

Live: mmi.services

The brief

MMI is the insurance-claims sister brand of mendmyi. The business has been running on the same codebase since 2008 - a content-managed install with a custom claims-handlers portal, an underwriters portal, a policy-holder login surface, an ecommerce module, an integration to a remote database host, and (until recently) a third-party email queue, a dead bookkeeping diagnostic that hadn’t worked since 2016, and several escaping patterns from a different era of web development. The site worked. It also took six and a half seconds to load the login page, five and a half seconds to render a logged-in claims-handlers list, and was sitting on a root volume at 95% capacity with 248,000 photo files in an unindexed uploads tree.

The off-the-shelf advice from any other agency would have been “rewrite the lot”. That answer is wrong for a business actively processing live insurance claims on the system: every legacy form, every claims-handler workflow, every underwriter sign-off path is load-bearing, and the cost of the rewrite that takes nine months and ships half-finished is the business stopping. The right shape is: modernise in place where it’s measurable, separate the marketing surface from the line-of-business system so the public-facing brand stops being constrained by the legacy stack, and treat every fix as an incremental bet against a clear before / after measurement.

The split - modern marketing site at the front, legacy LOB system still running behind

What we built (and continue to build)

The split. The apex of the site now resolves to a small front layer that pattern-matches the URL: legacy paths (the claims-handler portal, the underwriters portal, the policy-holder login, the legacy assets and uploads) proxy through to the legacy origin. Everything else falls through to a fresh deployment of the new marketing site. The line-of-business users keep their bookmarks; the public-facing brand stops being trapped behind the legacy stack.

The new marketing surface. A static modern build, recovered from the live site’s markup where no source repo existed, stripped of the previous build’s scoped-style attributes, and redeployed to a modern static-hosting target. Apple, IT, mobile, and tablet repair-service brochure pages plus the legal stack - fast, indexable, brand-led, and unencumbered by the legacy system that runs the business.

The legacy performance pass - measurable wins. Every fix logged with a before / after measurement against the origin (cache bypassed, so the numbers are honest):

The disk-cleanup that the system couldn’t do for itself. The legacy uploads tree carried 248,000 PRE- and POST-claim photo files across 25,398 paired job folders - 53 GB on a 60 GB root volume at 95% capacity. Cleaning it required surviving two filesystem gotchas - folder names containing spaces (like PRE-AVON AND SOMERSET-122976) that shred awk-on-whitespace pipelines, and folder names with leading dashes after the prefix that rm interprets as flags - and a migration-time caveat: the entire tree was rsynced years earlier without preserving modification times, so the filesystem’s mtime can’t be the cutoff signal for any future archival sweep; the archival cadence drives off the database job date instead. Outcome: 35 GB freed, 17,255 folders removed, the tree from 53 GB to 18 GB, root volume from 95% to 87%, all retention rules pre-agreed with the business owner.

The security audit and the incremental remediation. The codebase carries several escaping patterns from a pre-prepared-statement era and multiple raw uses of client-supplied address fields. The audit catalogues every instance with severity, fix shape, and per-fix risk of regression, and the remediation track works the same way as the performance pass: one fix at a time, each against a measurable before / after, each verified in production before the next lands.

The pricing model alongside. The Python pricing-engine work that sits alongside the claims-handling system is being modernised on its own track - explicit per-export verification, debug-formula scripts, and a clear path from the legacy spreadsheet model to a maintainable codebase.

An editorial flat-lay showing before / after timing measurements - login page, claims-handler list, new-claim form

The outcome

The marketing surface - the public-facing brand - is a modern site. The legacy line-of-business surface that runs the actual business is faster, lighter, leaner, and on a clear modernisation track that doesn’t require a nine-month rewrite. The disk that was a week away from running the business into outages now has the better part of a year’s headroom. The login pages that took six and a half seconds load in a third of a second. The claims handlers spending five-and-a-bit seconds per page load on a system they use all day get four-plus seconds back per page click.

For new clients, MMI Services is the reference for “we can take over what you’ve got and modernise it in place, without forcing a rewrite that breaks the business”. The shape ports to a 1990s solicitors’ case-management system that still runs the files but groans under the AML and source-of-funds workflow, a construction firm’s legacy programme or contract software the original developer no longer supports, a funeral director’s established case-management install where modernisation has to live alongside the legacy stack (the funeral-directors hub names this pattern explicitly), a letting agent’s multi-stakeholder approval workflow that evolved across three different software vendors, and any vertical where the original system works, the business runs on it, and “rewrite from scratch” is the wrong answer.

The same take-over-and-modernise pattern across three verticals - solicitors, construction, funeral directors

Which verticals this fits

The reference for any vertical where a legacy line-of-business system still runs the business and a rewrite-from-scratch is the wrong answer:

Regulated and professional services

Sensitive local and specialist contexts

Reactive trades doing insurer-pipeline work

Which problems this solves

MMI Services is the live example for the legacy-modernisation cluster of solutions:

Want us to take over and modernise your legacy system?

Tell us what runs the business today and where it hurts - the system the original developer no longer supports, the page that takes five seconds to render, the disk that’s at 95%, the security issue your last audit flagged that you never got round to fixing. We’ll take a look, scope the modernisation as a series of measurable bets rather than a rewrite, and come back with a sketch of the first three fixes and the before / after each one buys you. No demo, no calendar widget - email reply, scoped sketch, you decide.

Tell us what's slowing the business down

Send an enquiry - what you do, what's slowing you down, what you've already tried. We'll come back with a sketch of what we'd build and what it would cost. No calendar, no demo to sit through.

No calendar widgets. Email reply, scoped sketch.

Tell us what's slowing the business down

Email reply, scoped sketch, you decide. No calendar widgets, no demo to sit through.

No calendar widgets. Email reply, scoped sketch.