Why We Rebuilt Our Mission-Critical System Using Our Own Methodology

Would you get in an airplane built by engineers who refuse to fly in it?

Would you hire a chef who won’t eat at their own restaurant?

Would you trust a consultant’s methodology if they won’t use it on their own systems?

These questions answer themselves.

Yet it’s surprisingly rare to find software consultancies using their own methodologies on their own systems. Weird, right?

In early 2025, we decided to rebuild our 20-year-old business management system using the same Hybrid Migration Methodology we recommend to clients.

This wasn’t a side project. This was our business. Our data. Our daily operations.

Everything we tell clients about risk mitigation, zero downtime, and maintaining productivity? We had to prove it worked on ourselves first.

Here’s what happened.

The Challenge: 20 Years of Technical Debt

The Limelyte Extranet began in 2006 as a PHP 5 application on Kohana. At the time, perfectly reasonable.

It worked. It grew with us. It served us well.

But by 2024, the cracks were showing:

Maintenance sucked. Old PHP frameworks. Nobody wants to work in them. Including us.
Mobile was painful. jQuery-based interface on phones. Enough said.
APIs were limited. We wanted AI integration. The data was there—20 years of it—but accessing it programmatically was a nightmare.
Performance was declining. Report generation that used to be instant now took 10+ minutes.
Modern features were expensive. Every new feature meant navigating years of technical debt.

We had three options:

Keep patching it. Kick the can down the road. Watch productivity decline.
Big Bang rewrite. Shut down the old system. Build new everything. Pray the cutover works. Force everyone to switch on a specific date.
Hybrid Migration. Build new alongside old. Migrate entity by entity. Let the team transition at their own pace.

We chose option three. After 26 years, we’ve seen too many “big bang” rewrites fail catastrophically.

Why Hybrid Migration Made Sense

The traditional “big bang” approach: stop development, build everything in isolation, pick a date, flip the switch, hope for the best.

The problems are well-documented:

Frozen features. Your business can’t evolve while you’re rebuilding.
Massive integration risk. You don’t discover problems until cutover day.
Forced adoption. Everyone must switch at once.
Single point of failure. If anything goes wrong, everything’s affected.

Hybrid Migration is different. Build new alongside old. Share the same database. Migrate one entity at a time. Let users switch at their own pace. If something breaks, it breaks for one part, not everything.

But here’s the thing: until you use a methodology yourself, you don’t really know if it works. Theory is clean. Execution is messy.

We needed to know.

The Six-Month Journey

January 2025: started building. June 2025: done. Here’s what happened:

Phase 1: Foundation (January - February)

New backend in Go. Comprehensive REST API. Frontend in Flutter for web, desktop, and mobile from a single codebase.

Critically: both systems read and write to the same PostgreSQL database we’d been using since 2006.

This is where Hybrid differs from traditional rewrites. No new database. No “data migration.” Just a new system operating on existing data, in production, while the old system kept running.

Phase 2: First Entities (February - March)

Started with companies and people. Straightforward entities without complex logic. New Go API could read and write them. Old PHP system could too.

Then projects. Then tasks. Each migration meant confronting architectural decisions from years ago. Some good. Some not.

Phase 3: Critical Systems (March - April)

Time tracking and invoicing. If these break, we can’t bill clients.

Built the new system. Deployed to production. Started using it while the old system stayed available. Every timer we started was a test with real stakes.

If this broke, we’d be back to spreadsheets. Not an option.

Some team members switched immediately. Others waited months. That’s Hybrid Migration—switch when comfortable, not when forced.

Phase 4: API-First Development (April - May)

With core functionality stable, we started building interfaces. But not in the traditional order.

First: API

Everything started with the API. Every piece of business logic lived in the Go backend as REST endpoints. By building the API first, every feature could be accessed programmatically from day one.

Second: CLI

Instead of web first, we built a command-line interface. Why?

CLI development is fast. No styling, no complex UI, no cross-browser issues.
Every CLI command auto-generates MCP tools. Build today, use with AI tomorrow.
time start LTGEXT "Meeting" is faster than browser → navigate → click → fill.
If it works in CLI, the API is solid.

Third: Mobile

Flutter gave us native iOS, Android, and web from a single codebase. Mobile became the second-most-used interface. Track time while walking between meetings? 10 seconds.

Finally: Web UI

Web came last. By then, we’d used the system for months. We knew what got used constantly and what didn’t. Web UI designed on real usage, not assumptions.

API → CLI → Mobile → Web is now standard. New features ship fast through CLI, immediately available to AI, then get polished UI later.

Phase 5: AI Integration (May - June)

226 Model Context Protocol tools. 88 cloud-based. 138 CLI.

20 years of business data, now accessible through natural language.

“What did I work on last Tuesday?” Answered in seconds.

Documentation 10x faster. Report generation conversational.

Phase 6: Final Migration (June)

By June, most of the team had migrated. Usage of the old system dropped to near zero. We sunsetted it.

Total downtime? Zero.

Data integrity issues? None.

Team productivity? 95%+ throughout.

Living With the New System

We’re constantly pushing updates. Not occasionally. Constantly.

Deployment: Old system required careful staging, coordination, low-usage windows, fingers crossed. We dreaded deployments. New system? Deploy multiple times per day. Go backend is rock solid. No fear.

Type safety: Go catches bugs at compile time, not runtime. Saved countless debugging hours.

Auth: Implemented Goth with OAuth providers, role-based access, proper security. Not bolted on as an afterthought.

Feature velocity: Want a new report? Build API endpoint, create CLI command, test. Useful? Add mobile view. Used constantly? Polish the web UI. Want AI integration? CLI auto-generates MCP tools. Zero extra work.

This velocity was impossible in the old system.

What We Learned

Theory is clean. Execution is messy.

API-First Changes Everything: Building comprehensive APIs first meant adding interfaces (web, mobile, CLI, AI) without touching backend logic. API → CLI → Mobile → Web isn’t just preference—it’s strategic. Prototype features in hours. Auto-generate AI tools. Fundamentally changed how we develop.

Teams Migrate At Different Speeds: Some switched day one. Others waited months. Both fine. Forced migrations create resistance. Voluntary migrations create champions.

Type Systems Prevent Bugs: Moving from PHP to Go seemed like a trade-off: slower development for reliability. Wrong. Once we adjusted, development got faster AND more reliable. Terrifying refactors became routine.

The Results

Let’s talk numbers:

Migration timeline: 6 months
Downtime: 0 minutes
Data integrity: 100% across 20 years of financial records
Time tracking: 5 minutes → 10 seconds
Report generation: 10 minutes → instant
Team productivity: 95%+ maintained throughout
AI integration: 226 tools making 20 years of data accessible
New feature velocity: 3-5x faster

But numbers don’t capture the qualitative shift.

We went from dreading working in our own system to enjoying it. From fearing deployments to deploying confidently multiple times per day. From wishing we could modernize to actively building the future we wanted.

That’s what successful migration looks like.

What This Means for You

If you’re running on aging software, you know the choice:

Keep patching, watch productivity decline
Risk a big bang rewrite
Hybrid Migration

The question isn’t whether you need modernization. You already know you do.

The question is how to get there without destroying your business.

Hybrid Migration offers:

Small failures are recoverable. Big bang failures are catastrophic.
Your team keeps working while the new system is built.
People switch when ready, not when forced.
Ready for AI from day one.

We used this on our own business-critical system. We bet our business on it.

That’s the difference between theory and reality.

Ready to Talk?

We rebuilt our 20-year-old system using the same methodology we recommend to clients.

We’re living with the results every day. Every timer we start, every invoice we generate—it’s all on this system.

This isn’t theoretical. This is our daily reality.

Looking at an aging system? Wondering how to modernize without the risk?

Let’s talk. We’ve done it to ourselves first.

Related Case Studies: