Senior TypeScript developer for legacy code modernization

How to tell that the code is slowing you down

Legacy code is not a dirty word. Usually it's code that earns money; otherwise someone would have shut it down long ago. It becomes problematic when it prevents change. The signs are similar in almost every company.

• A change in one place breaks something elsewhere, and no one knows where in advance.
• There is a module that only one person is willing to touch, and that person will be on vacation soon.
• New hires take months to become productive.
• Automated tests are missing or have been failing for weeks, and everyone has gotten used to it.
• Dependencies are years old, such as AngularJS, whose support ended in late 2021, or versions of Node.js without security updates.

If two or more of these points apply, you're already paying for this state every month — it just doesn't show up on any invoice. It's baked into slower releases, customer-facing errors, and people who eventually quit because the work is no longer enjoyable. On the page about JavaScript developer We describe how we typically approach such codebases.

Why experience matters more than speed here

Modernization is primarily risk management. It's not about rewriting as much as possible as quickly as possible, but about making the system incrementally safe to change while it remains operational. This is where a senior engineer most clearly differs from less experienced engineers.

A senior TypeScript developer knows which parts you should not touch right now. They estimate realistically rather than make promises, and can explain to management why the next month will be spent on tests rather than features. Above all, they can say no when a refactor brings more risk than benefit.

Seniority has little to do with years. Some people with twelve years’ experience have lived the same year twelve times. How to recognize real experience is explained later in this article.

Incremental, not Big Bang

The temptation to rebuild everything is great. Software history is full of rewrites that took years while the old application had to keep running and no one received new features. The Netscape browser is the best-known example.

The pattern Martin Fowler calls the Strangler Fig has proven effective. Your code grows around the old system, taking over functionality function by function, and the old system shrinks until it can be shut down. Here’s how a JavaScript-to-TypeScript migration looks in practice.

1. Stabilize builds and tests. A pipeline that reliably runs and tests the key processes before anything is changed.
2. Introduce TypeScript without rewriting anything. With allowJs, JavaScript and TypeScript run side by side; with checkJs and JSDoc comments, even older code gets type checks.
3. Type boundaries first. Interfaces, data models, and all external inputs—that's where most errors originate and where types help most.
4. Increase strictness incrementally. Start with strictNullChecks, because missing null checks are the most common source of errors; then enable the remaining strict mode options.
5. Migrate module by module. Each module is fully migrated, tested, and rolled out before the next one is tackled.

Four pitfalls that can stall a migration

Most migrations fail not because of technology, but due to habits that creep in along the way. Someone on the team should watch these four.

• "any" as a long-term solution. Covering every hard spot with any leaves you with TypeScript files that lack TypeScript's benefits. A linter rule and a declining monthly target keep this in check.
• Types that lie. An assertion using as tells the compiler to trust even when the data may say otherwise. At the boundaries, you should therefore include a runtime check, for example, with Zod.
• Huge pull requests. No one reads a review of over two hundred files thoroughly. Small steps feel slower but deliver results faster.
• Migration and refactoring in the same step. Introducing types while changing logic makes it hard to spot bugs afterward. The rule: add types first, refactor after.

A senior watches for these points not only in their own code but also in reviews for the rest of the team. That creates a shared way of working that endures even when external support is reduced.

A compiler upgrade is a good opportunity.

Since July 8, 2026, there is TypeScript available. The compiler was ported to Go and is, according to Microsoft, typically eight to twelve times faster for full builds. For the VS Code codebase, build time dropped from around 126 at just under 11 Seconds. For large codebases where type checks previously took minutes, this makes a big difference in day‑to‑day work.

For legacy projects, the new version has a catch. TypeScript adopts the defaults from version 6, and they're strict. Strict Mode is now enabled by default, and old settings like target es5, moduleResolution node10, or baseUrl result in hard errors. If you’re still using a configuration from five years ago, you’ll need to clean it up first.

It also means TypeScript 7.0 doesn't yet provide a stable programmatic API. Tools that access the compiler directly, such as linters, therefore run in parallel with TypeScript 6 for now. For Vue, Astro, Svelte, or MDX, the editor initially stays on version 6, and Angular template type checking also doesn't yet use TypeScript. Microsoft has announced a new API for version 7.1.

An experienced developer plans this in two steps. First, migrate to TypeScript 6 with the new standards and fix all warnings. Then add TypeScript to the CLI build and pipeline, while the editor continues to run version 6 where needed. How we implement this in projects is described on the page Hire TypeScript developers. For projects with Vue and Angular, see the respective pages.

What you should measure during modernization

Without numbers, modernization becomes a matter of belief. With a few simple metrics, you can see each month whether the effort is paying off.

• Share of files in TypeScript and the number of remaining any types
• Duration of build and type check in the pipeline
• Production errors per release
• Ticket lead time from idea to go‑live
• Time until a new person submits their first pull request

The trend matters more than the absolute value. If the number of bugs falls and cycle time shortens, you’re on the right path—even if half the code is still in JavaScript.

The first 90 days

A realistic quarterly plan for a medium‑sized codebase looks roughly like this.

First month

Analysis and hardening. The senior reviews code, speaks with the team, and creates a risk map. A simple method is a look through Git history: files that change often and cause many bugs are the hot spots. In parallel, the pipeline is stabilized and the most important workflows get tests.

Second month

Boundaries and initial strictness. TypeScript is introduced, interfaces and data models are typed, and strictNullChecks are enabled in the first modules. The team sees the initial errors the compiler catches before they reach customers.

Third month

The first module is complete. It’s migrated, tested, and running in strict mode. Metrics show what it delivered, and on that basis you plan the next quarter.

How to recognize a senior TypeScript developer

In conversations, seniors distinguish themselves more by the questions they ask than by their answers. Those who first want to know which parts of the system earn the most money and where most complaints come from think in terms of risks rather than technologies.

These three questions help with the assessment.

• Which file would you touch last in our codebase, and why?
• How would you prove that a migration didn't break anything?
• In what case would you advise us against a migration?

Pay attention to how someone works: small pull requests with clear descriptions, tests for every change, and review comments that explain rather than preach. With the Discovery package You see them in a real sprint before committing long-term.