Your product is old, every change breaks something, and the customers who pay for it monthly won't wait while you fix it. In our experience, a first call fills in the rest. Releases ship from someone's laptop with no staging environment, and the framework is out of support or close to it.
The founder of CondoGenie wrote it in 2009 as GeniePad, and from 2018 we replatformed it (rebuilt it as a new codebase). In August 2026 it shipped 5 production releases while we were moving its build tools to Node.js 24.
Legacy application modernization keeps a business running when what customers see stays stable and one part changes at a time, with the old path ready to take the traffic back. Everything below assumes a live product with paying customers. If the team that built yours has gone, start with project takeover, because access to the code and the cloud has to move before anything else does.
TL;DR: Make releases safe before you touch the product and list what must not move. Then change one module at a time with the old path deployable for 30 days, and move data in runs you can check and rerun. Brocoders rebuilt CondoGenie beside its original version, GeniePad, from 2018 and has upgraded it in place since, while CondoGenie's active users grew from 1,398 in 2019 to 19,324 in 2025.
Why legacy system modernization fails when you stop to rewrite
In our experience, legacy software modernization goes wrong on a live product when it follows a freeze-and-rewrite plan. That plan puts every risk on one cutover date and stops the work customers pay for while the new system gets built.
Until the cutover date, the old product keeps changing under the people rebuilding it, and customers wait for features.
In the US federal government, keeping old systems running takes most of the IT budget. A 2025 report by the US Government Accountability Office (GAO-25-107795) says federal agencies have typically reported spending about 80% of their IT budgets on operating and maintaining existing IT. On your own product, a stalled rewrite would mean paying for 2 systems at once, the one customers use and the one they can't use yet.
The safer pattern has a name, the strangler fig. New parts grow around the old system and take over its work one piece at a time, until the old code can be switched off.
A product with paying customers adds a constraint the pattern leaves out, the people who use it every day. When we began replatforming CondoGenie in 2018, the new interface had to stay close to the old one. That way board members and residents wouldn't have to learn a new product.
Step 1: make releases safe before you change anything
If a release can only go out from one person's laptop, every change to the product is a gamble. So the first step fixes the release path and leaves the code alone.
Lake is a US marketplace for vacation rentals by the water. It came to us in February 2025 with a WordPress monolith (one codebase where every part is tied to every other), no staging environment, and developers pushing changes from their own machines straight to production.
Before we rebuilt anything, we set up a GitHub repository and a staging environment with controlled deploys. From then on the team shipped production-ready features every 2 weeks.
Traders Alloy, a Swedish fintech, came to us after its previous vendor couldn't get a continuous integration and delivery (CI/CD) pipeline running. A single senior DevOps engineer built it on Jenkins across the backend and frontend, with automated tests, and trained the client's team to run it themselves.
We run this step as a Stabilisation Sprint of 30 to 90 days. Everything below is in place before any behavior changes:
- Reproducible builds, so the same code always produces the same release
- CI/CD, monitoring, and backups
- A minimum set of regression tests, which catch a change that breaks something that used to work
Step 2: list what must not move
Before you change what customers never see, write down what has to stay exactly as it is. We find 4 lists cover it:
- What customers see and touch: the screens and flows they use every day
- What customers pay: plans, amounts, billing dates, and the payment methods on file
- What earns: the pages and integrations that bring in customers or revenue
- What depends on you: other systems that read or write your data
For Lake, what earned decided the shape of the rebuild. Its WordPress content pages, the city pages among them, brought guests in from search.
The content pages stayed on WordPress to protect their search engine optimization (SEO) rankings, and we rebuilt only the core product. If you're migrating off WordPress, make that split your first decision.
What depends on you can mean the existing system stays where it is. C.I.A. Services, a homeowners association (HOA) manager in Houston and San Antonio since 1984, runs on RedDog. One of its founders wrote RedDog as a desktop system and led the rebuild with a development partner as RedDog NextGen in 2021.
Owners couldn't reach RedDog from a phone, so from 2022 we built them an owner app as a progressive web app (PWA, a website that installs and behaves like an app). It sits on top of RedDog's application programming interface (API), which returns only the records each owner may see. RedDog stayed the system of record, the system that holds the master copy of the data.
Step 3: change one part at a time, with the old path ready
Change one module (a part of the product you can release on its own) at a time, and keep the old path able to take the traffic back. Of the 4 ways below, ordered by risk to customers with the lowest first, pick the first one that removes what blocks customers.
| Way | What changes | What keeps running | Risk to customers | Where we did it |
|---|---|---|---|---|
| Extend | A new surface over the existing system's API | The system of record, kept in place | Lowest | C.I.A. Services: an owner app over RedDog |
| Upgrade in place | Runtime, framework, test suite, or payments API, one at a time | The whole product and its screens | Low | CondoGenie, 2025 to 2026: Playwright, Rails, Stripe API, Node.js 24 |
| Split | The blocking part rebuilt, the earning part kept | The earning part (content pages, SEO) | Medium | Lake: WordPress content pages kept, core product rebuilt |
| Replace beside | A new platform built next to the old one, data moved in runs | The old platform, until the last run | Highest of the 4, with no cutover weekend | CondoGenie, from 2018: GeniePad to CondoGenie |
Decide each module on its own. Whether a given module needs cleaning up in place, a new platform, or a full rebuild is a separate question. Our guide to refactor, replatform, or rebuild walks through it.
Before a switch, the module runs on the old path and serves every customer. After it, customers use the new path for that module, and the old one can still take them back. Every switch is held to the same 4 rules, the ones on our application modernization services page:
- Same requests, both paths: before traffic moves, the old and new paths receive the same requests, and we compare what they return.
- 30 days to go back: the old path stays deployable for 30 days after the switch.
- Re-sequence past 20%: if a module's estimate moves more than 20% at any point, we stop and re-sequence the work with you.
- 2 engineers per module: every module has at least 2 engineers on it, so no part of the product depends on one person.
The first rule uses real customer requests as the test. GitHub built Scientist, a library around the same idea. It runs old and new code side by side and returns the old result to the user while it records the mismatches.
Step 4: move data in runs you can check and rerun
Move customers and their data in batches you can check and run again, so a bad record stops one batch and the rest of the business carries on.
When we moved CondoGenie off GeniePad alongside feature work, 9 years of accounts, documents, and user histories went across run by run, while the business kept running. The early runs surfaced schema mismatches (fields that didn't line up between the old database and the new one) and records that didn't map cleanly. We repaired them run by run, inside the release timelines the business had to keep.
Billing changed on the live product too. CondoGenie's Stripe API version migration in February 2026 ran against live subscriptions.
Stripe works this way on its own systems. In Online migrations at scale, Jacqueline Xu of Stripe described how the company runs its many online migrations. Its pattern is to write to the old and new stores at once, move the reads, move the writes, and only then remove the old data.
One buyer described the same plan on a discovery call:
"... run this website ... concurrently while we build and then switch."
Communications and Creative Services Manager, a US residential community
CondoGenie, worked through: 8 years on a live condo SaaS
CondoGenie went through both kinds of change while customers kept using it: first a new platform built beside the old one, then upgrades in place on the live product. It is a software-as-a-service (SaaS) product for condo boards. On a live SaaS this work has no decommission date, and on CondoGenie it is 2018 to present, 8 years and ongoing.
Before 2018 CondoGenie was GeniePad. Rafal Dyrda built it in 2009 for his own condo board in Edmonton and later sold it to condominiums across the US and Canada. By 2018 it carried 9 years of features on an architecture built for one building.
On CondoGenie, 1,398 active users in 2019 became 19,324 in 2025, a 1,282% increase. The share of registered users who are active rose to 26% in 2025, from about 18%. As of October 2026, CondoGenie serves over 550 condominium and HOA associations and over 80,000 registered users, and it has grown from 6 features at launch to 23.
| When | What changed | What customers kept |
|---|---|---|
| 2009 | Rafal Dyrda built GeniePad for his own condo board | |
| 2018 | Decision to build a new platform beside GeniePad. Every existing behavior mapped first, undocumented edge cases included | The product logic, and an interface close to the old one |
| From 2018 | New codebase, new name, new interface, and a 3-tier multi-tenant structure. The tiers are condo accounts, the management companies above them, and a super admin, with each account on its own subdomain. First release after 18 months | |
| During the replatform | 9 years of GeniePad accounts, documents, and user histories moved run by run, alongside feature work | The business kept running |
| June to September 2025 | Test suite moved to Playwright | |
| Aug. 15, 2025 | Ruby on Rails upgrade released on the live platform | No customer-facing downtime |
| August 2025 | Genie, an AI feature that drafts announcements from a short prompt, went live | |
| February 2026 | Stripe API version migration against live subscriptions | Their subscriptions |
| May 13, 2026 | Plan upgrade automation with prorated annual billing | |
| August 2026 | 5 production releases. Frontend toolchain move to Node.js 24 under way | The release cadence |
Every year from 2018 to 2026, the team behind CondoGenie has been 2 full-time engineers plus a part-time project manager, with DevOps and quality assurance (QA) on call. As of August 2026, the codebase they work on has 1,806 modules across 4,241 files in 2 repositories. The full story is in the CondoGenie case study.
Lake, worked through: keep what earns, rebuild the rest
At Lake we kept the part of the product that earned and rebuilt the part that blocked growth, in 3 months.
David Ciccarelli, Lake's CEO and founder, put the problem this way in our write-up of how we rebuilt Lake: "The main issue was that property pricing and availability data didn't synchronize." In April 2025 he wrote on his blog that Lake had a backlog of more than 10,000 properties waiting to be onboarded, and that "it's time to revisit and rebuild."
We worked with Lake from February 2025 to July 2026. A team of 5 started the work (a product manager, 1 frontend developer, 2 backend developers, a part-time QA engineer, and DevOps on demand) and grew to 6 or 7 people.
Once the release path was safe, we kept the WordPress content pages and rebuilt the core product as a standalone web app in 3 months. For weeks, our team met the API team of Calry, the middleware that connects Lake to property management systems, twice a week to work through the sync.
Lake's own announcements date what followed:
| Date | What Lake said | Source |
|---|---|---|
| June 20, 2025 | 5 new property management system integrations "after a complete overhaul of the platform" (6 connections in total) | Lake press release |
| Jan. 12, 2026 | "40,000 active rental properties across 36 countries" against a goal of 30,000 for the year | Lake press release |
Lake grew from ~500 to 40,000 connected properties, an 80x increase. More of this work is in our migration case studies.
"We'd worked with several other teams before, but they couldn't pull off what you [Brocoders] did."
David Ciccarelli, CEO and founder, Lake, in our Lake case study
When this approach is the wrong one
Running 2 paths costs money. For at least 30 days after each switch you pay to keep the old path deployable, and the calendar runs longer than a rewrite plan promises on paper.
Reach for something else in 2 situations. If the product has no paying customers yet, rebuild it, because no customer is waiting on the old version. If the business has changed what it sells, write the new specification first, because the old system describes a business that no longer exists.
If you can't say what the current system does, start with a software audit before you pick any of this.
How we run a modernization at Brocoders
We run the work in 4 stages, and you can stop after any of them:
- Software audit: 5 or 10 business days, fixed scope. You get an architecture map, a dependency graph, a security and data review, a test-coverage assessment, a prioritized risk register, and a written refactor-versus-rebuild recommendation that is permitted to say do not rebuild.
- Stabilisation Sprint: 30 to 90 days of reproducible builds, CI/CD, monitoring, backups, and a minimum regression-test safety net.
- Incremental decomposition: module by module, ordered by what would break the business soonest, with the product live throughout. A decomposition pod for this stage costs $25,000 to $60,000 a month.
- Senior engineering pod: a team that ships features on the new platform against delivery key performance indicators (KPIs) published at the start.
Start with the audit if you're unsure which of the 4 ways from Step 3 each module needs. It answers that before anyone quotes a rebuild. The rest of the path, with prices, is on our application modernization page.
Start with the release path and the must-not-move list
You can start this week with 2 checks: whether a release can go out without one person's laptop, and which screens, bills, pages, and integrations must not move. Then pick the one module that blocks customers now.
If you want a second opinion before you commit, a fixed-scope software audit gives you a written recommendation in 5 or 10 business days. To see the path on live products first, read our modernization case studies or the application modernization overview.
Frequently Asked Questions (FAQ)
Fix the release path first and list what must not move. Then change one module at a time while the old path stays deployable, and move data in runs you can check and rerun.
The worked example is CondoGenie, which Brocoders rebuilt on a new platform beside its original version, GeniePad, from 2018 and has upgraded in place since.
Decide per module. Rebuild a module beside the old one when it blocks customers and can't be fixed in place, and upgrade the rest. Lake kept its WordPress content pages and rebuilt its core product in 3 months.
Brocoders' fixed-scope software audit makes that call in 5 or 10 business days, with a written refactor-versus-rebuild recommendation that is permitted to say do not rebuild. The full decision is in our refactor, replatform, or rebuild guide, and the code-level version in refactor vs. rewrite.
The software audit takes 5 or 10 business days and the Stabilisation Sprint 30 to 90 days, and after that the work runs module by module. We rebuilt Lake's core product in 3 months. On CondoGenie we have worked for 8 years, first on a new platform beside GeniePad from 2018 and then on in-place upgrades to the live product.
Brocoders' Stabilisation Sprint costs roughly $40,000 to $120,000, and a decomposition pod for the module-by-module work costs $25,000 to $60,000 a month. Both figures are in our published modernization price ranges. The first step is a fixed-scope software audit, and it may recommend no rebuild at all.
Move the data in runs, a batch of accounts at a time, each checked against the source and rerun until it matches. The old system keeps serving customers the whole time. CondoGenie's 9 years of GeniePad data moved in runs, with mismatches repaired run by run, while the business kept running.
CondoGenie is one. It started in 2009 as GeniePad, a condo management product built for one board, and Brocoders replatformed it from 2018 into a multi-tenant SaaS. Active users grew from 1,398 in 2019 to 19,324 in 2025, and as of October 2026 the platform serves over 550 condominium and HOA associations.
Yes, and most of the work in going from legacy to SaaS is what a product built for one customer never needed. That covers keeping each customer's data apart (tenant isolation), billing that knows which plan each customer is on, and usage metering, which counts what each customer uses for billing or limits. It also covers roles beyond employees, an audit trail, and security that passes a customer's review.
GeniePad was built for one condo board, and CondoGenie now runs as a 3-tier multi-tenant SaaS. If you built software to run your own operation and other companies now want to buy it, see how to turn an internal tool into a SaaS product.
Then access moves before code does. Repositories, cloud accounts, credentials, and documentation come under your control first, and only then does anyone change the product. That's our project takeover service, and it starts with the same software audit.