Migration and refactoring of legacy — without halting the business.
Old code is rarely truly bad — it's usually just tired. We move projects from Bitrix, WordPress, Yii, CodeIgniter, and custom CMSs onto a modern stack gradually, in pieces. None of the "let's rewrite it all from scratch in a year" trap: first the surrounding parts, then the modules, then the core. The business keeps running, customers don't notice a thing.
§ 07.1 Typical situations
WordPress site with 40 plugins
Slow, breaks on every update, full of vulnerabilities. We move content to a headless CMS (Sanity, Directus) with a Next.js or Astro front-end. URLs stay intact, SEO doesn't drop.
A Bitrix store you can no longer grow
Every change costs as much as half a new site. We move it to a headless architecture: Bitrix stays as the back-end (or 1C as the data source), the front-end becomes modern, fast, and properly indexable.
A custom PHP project with no docs
One developer quit, the next one is afraid to touch it. We assemble documentation, cover the critical path with tests, then gradually port to Node.js or Go.
Old Ruby / Django
Decade-old projects, dependencies untouched for years. Version upgrades, migration to modern ORMs, extracting internal services.
Front-end on jQuery
500 KB of "just in case" JS, three versions of jQuery in one file. Gradual extraction into React / Svelte islands, then a full replacement.
A large monolith
Carving out modules with clean boundaries, the strangler-fig pattern: new features in the new stack, the old code peeled off bit by bit. No "big bang" rewrites.
§ 07.2 How it works
- A week of discovery: we read the code, map the system, find the critical bits, and talk to the team.
- A plan as a sequence of steps: what moves first, what moves second, which metrics we check after each.
- Tests on the critical path — so refactoring doesn't break checkout or delivery.
- Old and new running side-by-side until we're sure the new side hasn't broken.
- Traffic switchover, monitoring, rollback at the first hint of trouble.
- Documentation: system diagram, runbooks, guides for your team.
§ 07.3 What we usually advise against
A full rewrite from scratch. It's almost always more expensive, slower, and riskier than it looks at the start. Twelve months into rewriting on a new project, you typically discover the old code held fifty undocumented business rules — and now the users are angry. Step-by-step is better.
Changing the technology just to change it. If your old PHP works and isn't holding the business back, leave it alone. Touch it when the old stack actually blocks growth, security, or performance.
Microservices for a two-person team. The complexity of distributed systems usually costs more than the gain. A modular monolith is almost always the right starting point.
§ 07.4 FAQ
How long will it take?
Depends on size and condition. A small WordPress content site — 2–3 weeks. A mid-size Bitrix store — 6–10 weeks. A large monolith is a multi-month story where planning and priorities matter the most.
Can we migrate without downtime?
In 90% of cases — yes. Run the old and new sides in parallel, then switch over gradually by endpoint or by traffic share. Real downtime usually only happens at the database cutover, and that's typically a few minutes.
Our former developer won't release the source code.
An unpleasant situation, but a solvable one. We help arrange the legal handover of the source — or we reconstruct the project from the running version. Slower, but doable.
Will SEO survive the migration?
Yes — that's a baseline requirement: URL structure, 301 redirects, sitemap, canonical addresses, every meta tag. We verify before and after via Search Console and Yandex Webmaster.
Show us
where it hurts.
hi@weiss.help ↗
First 20-minute call — free. Migration plan after discovery.