Who this is for
You have a working frontend that's three or four years old. It still ships revenue. But the framework is end-of-life or close to it, the build is slow, half your dependencies have major versions you can't take, and every new hire spends their first week asking why.
Three migration shapes I see most often:
- Vue 2 + Quasar → Vue 3 + Vite — Options API to
<script setup>, Vuex → Pinia, custom replacements for Quasar components, vue-query → @tanstack/vue-query. - AngularJS (1.x) → React or Vue 3 — usually a strangler-fig migration, route by route, with a shared shell.
- React class components → hooks + modern routing — often bundled with CRA → Vite or Next.js, and Redux → Zustand or TanStack Query.
What you get in two weeks
01 — Per-component complexity score
Every component in the codebase gets a score (trivial / moderate / hard / risk) based on composition-API conversion difficulty, third-party component replacement, state-management coupling, routing changes, test coverage, and how much business logic lives in the template vs the script.
02 — Concrete effort estimate, in days
Not "small / medium / large." A real number with a confidence interval, derived from per-component scoring of your actual codebase. You can put it in a spreadsheet, multiply by a rate, and have a budget conversation with finance.
03 — Risk register with mitigations
Every item that could derail the migration, written down explicitly with
a proposed mitigation and a "what we'd do if this hits" plan. Things like
lost OTP/2FA flows, dialog systems changing from imperative to
v-model, print-CSS rules that never made it across, or HTTP
clients that quietly merged into one and lost their separation of
concerns.
04 — Migration plan, ordered
A sequence that lets you ship in increments — not a big-bang rewrite. Strangler-fig where possible, parallel routes where not, and explicit checkpoints where you can stop and re-evaluate without throwing work away.
How the two weeks look
- Day 1–2: repo access, build environment, dependency graph, line-count and complexity scan.
- Day 3–5: per-component pass. Each component opened, scored, notes written.
- Day 6–7: interviews with whoever's left who knows the system. The undocumented invariants always live in someone's head.
- Day 8–10: store / routing / HTTP / build pipeline analysis. Where the architectural pain actually is.
- Day 11–13: writing. Effort numbers, risk register, ordered plan.
- Day 14: 90-minute walkthrough with you and your team. Q&A. Adjustments.
What you can do with the report
- Budget the migration with your CFO using real numbers.
- Decide who executes — your team, my studio The Gyld, or a mix.
- Decide whether to migrate at all. Sometimes the right answer is: not yet. The report makes that visible.
- Set realistic deadlines you'll actually hit, instead of the optimistic ones that everyone privately knows aren't real.
What I bring to it
Ten years building production frontends, including three Vue 2 → Vue 3 migrations end-to-end and a custom static-analysis toolkit that I use to seed the per-component scoring. Founder of The Gyld, a small Athens-based studio that handles execution when you want one contract for audit and delivery.
Frequently asked
How long does the audit take?
Two weeks from kickoff to written report.
Can you also execute the migration?
Yes — via The Gyld, with me staying on architecture and reviews. Execution is quoted from the audit itself, so the number you get is the number you pay.
What if my codebase is too messy to estimate?
That's what the audit is for. Messy codebases get a clearer report, not a worse one, because the unknowns are explicitly logged as risk items with mitigation plans.
Do you do backend migrations too?
Yes, but it's not the focus of this audit. Common pairings: Django 2 → 4, Node CommonJS → ESM, Express → Fastify, Rails 5 → 7. Ask in the intro call.
Want a yes/no on whether your migration is feasible?
Send a short note — the repo size, the stack, and what's making this urgent.
Email Eirini → Back to main site