Stuck in GeneXus? Get out and ship faster.
Every change goes through the generator, the few people who can read the knowledge base, and a release cycle you don't control. We move your system to React and .NET, side by side with GeneXus and on your same database: no data migration, no big-bang cutover, and your team keeps shipping while we do it.
The generator was the shortcut. Now it is the bottleneck.
GeneXus got a lot of software built fast. Years later, the same model that sped you up is what slows every change down.
Every change goes through the generator
A field, a rule, a screen: model it in the knowledge base, regenerate, rebuild, redeploy. What takes minutes in a modern stack takes days, and it needs a specialist.
The business lives in a KB few can read
The knowledge base is the only complete map of your rules, and fewer people can read it every year. Hiring for it is slow and expensive, and every departure is a risk.
Hard to test, hard to integrate
Automated tests, CI/CD, modern APIs, responsive screens, AI features: all of it fights the generated code instead of working with it.
Upgrades on someone else's calendar
Every generator version bump is a project of its own, and the licenses stay for as long as a single screen still depends on it.
No rewrite from memory. No leap in the dark.
Modernizations fail when the new system is built from what people remember the old one does. We build it from what the old one actually does, next to it, on the same data.
Side by side, on the same database
The new system runs next to GeneXus on the same SQL Server. It starts read-only, with new screens over real data, and takes over module by module. No data migration, no cutover weekend, and the original never stops.
The knowledge base is the spec
Every business rule is taken from the exported GeneXus source, with the file and line cited in the new code. Nothing reinterpreted, nothing guessed, and the KB finally becomes readable.
The original's screen decides
Before deciding anything, we measure it on the running system: labels, validations, how each dropdown behaves. When the source and the screen disagree, the screen wins.
Writes that never duplicate
Writes go through our own stored procedures in a separate schema: idempotent (a retry never creates a duplicate), with an audit log of who did what, a backup before any delete, and isolation per tenant.
Every divergence in writing
We copy the original, unless copying it would show wrong data. Any difference is written down with its reason before it ships, so you always know what changed and why.
Thousands of tests against real data
Tests run against your own test database, each with a planted bad case: a test that can't fail doesn't count. A daily canary runs reference operations on both systems and compares the results.
Module by module, on your schedule.
Your team keeps shipping the whole time. You decide when each module leaves GeneXus.
Read
We take your knowledge base export and your database schema and map every object, rule and integration. You get the plan: modules, order, risks.
Mirror
New screens go live over your real data, read-only, next to GeneXus. Your users start working with them with nothing at risk.
Parity
Module by module, writes switch on. Each one is tested against your data, every difference is declared, and your users validate it.
Switch off
When a module reaches parity, you retire it in GeneXus. When the last one does, you stop needing the generator.
- React + Vite
- .NET API
- Your same SQL Server
- Same users (GAM), then your identity provider
- CI/CD with a test gate
- Your cloud, your repositories
Six years of GeneXus, parity in a month.
A multi-tenant insurance platform built in GeneXus over about six years and roughly USD 300,000: quoting across several carriers, policies, claims, issuing, importers, users and permissions. This is how the first month went.
- Day 1
Read-only mirror live: new screens reading straight from the real database.
- Day 2
Login against the original user base, the data model mapped from the knowledge base, and the core engine and its integrations rebuilt from source.
- Week 1
First modules with writes, through our own procedures, while GeneXus kept working on the same data.
- Month 1
Functional parity on the core modules. Now in validation with the client, side by side with the original.
What teams ask first.
Do we have to migrate our data?
No. The new system works on your current database. Its own objects live in a separate schema, so nothing of the original is altered, and both systems see the same data at all times.
Can we keep shipping in GeneXus meanwhile?
Yes. Both run side by side on the same data. Modules that haven't moved yet keep getting changes in GeneXus until their turn comes.
What happens to users and permissions?
The new system authenticates against the same user base (GAM) the original uses. People log in with the credentials they already have, and each tenant only sees its own data. Later you can move to your own identity provider.
What about integrations and web services?
Each one is rebuilt from the original source and validated against the provider's test environment before it carries real traffic.
Does it have to be React and .NET?
It is what we recommend for a GeneXus .NET shop: your team already knows the platform and SQL Server stays. If your team works in another stack, we plan for it on the first call.
How long would it take for our system?
It depends on the size of your knowledge base and on the integrations. For reference, about 4,900 objects and ten external integrations reached functional parity in a month. On a call we look at your numbers and give you an estimate.
Who owns the result?
You do. The code lives in your repository and the infrastructure in your cloud accounts. We stay available; we don't stay necessary.
Bring your knowledge base. We'll bring the plan.
A 30-minute call. Tell us the size of your system, its modules and its integrations, and we tell you what a side-by-side rebuild would look like, how long it would take and what it would cost.