Legacy Flutter Rescue: What We Learned Migrating Libero Health to Production

Libero Health came to us as a stalled build: a telehealth platform with appointment booking, video consultations, e-prescriptions and health records, built on an old Flutter version by a previous team that hadn't finished. The instinct with inherited code is often "rewrite it all." That's usually the wrong call.

Audit before you touch anything

Before writing a line of code, we mapped what actually worked, what was half-built, and what was quietly broken. A rewrite driven by frustration instead of evidence tends to re-introduce the same bugs in new code, just more slowly.

Migrate the framework, don't fight it

Moving to the latest Flutter version first — rather than layering new features on an outdated one — meant every feature built afterward used current APIs and packages instead of workarounds for a version already falling out of support.

Finish, then harden

Once the framework was current, we completed the remaining product features against the existing data model instead of redesigning it, then took the whole thing through to production deployment. The result: a real telehealth product actually shipped, not a rewrite that took twice as long and delivered the same feature set.

The general lesson

A stalled or inherited codebase is rarely worthless. The cost of understanding it is almost always lower than the cost of rebuilding it from nothing — which is the same judgment call we make on every legacy rescue or AI-prototype scale-up project since.