Hire a Freelance Symfony Developer: What to Look For in a Legacy Project

Your Symfony application has been running the business for years, and the person who built it is gone. You need someone fast, so you post a job to hire a freelance Symfony developer and the applications start arriving. Most look fine on paper: a tidy portfolio, a few years of Symfony listed under skills, maybe a certification or two. None of that tells you whether this person can walk into a six-year-old codebase, make sense of what is already there, and keep it running while they fix it. Hiring a freelance Symfony developer for a legacy project is a different exercise from hiring one to build something new, and the screening questions should be different too. The rest of this guide covers what actually separates a hire who can handle your codebase from one who will struggle on it for months at your expense.

Why hiring a freelance Symfony developer for legacy work is its own skill

A developer who is excellent at starting fresh projects can still struggle badly with an inherited one. Building new code lets you choose your own patterns and work at your own pace. Legacy work means reading someone else's decisions, often made under deadline pressure years ago, and figuring out which parts are load-bearing before you touch anything. The developer has to resist the urge to rewrite everything they disagree with, because a rewrite introduces risk the business did not ask for.

During a first call, ask the candidate to describe the last time they inherited a codebase they did not write. Listen for how they approached the first week. Someone who talks about writing tests around the parts they needed to change before refactoring is giving you a good sign. Someone who talks mainly about how they would have built it differently is telling you something too, just not what you want to hear.

Ask about the version history, not only the current version

Symfony has gone through major changes since the 2.x days, and a codebase that started on Symfony 2 or 3 and was never fully modernized carries scars from each release along the way. A developer who only knows Symfony 6 or 7 from greenfield projects may never have dealt with the bundle system from the 2.x era, the service container changes introduced in 3.x and 3.4, or the jump from annotations to attributes for routing and configuration.

Ask the candidate to walk you through what changed at each major Symfony version boundary and what usually breaks during an upgrade. If your own application has a convoluted version history, our guide on migrating from Symfony 2/3 to Symfony 7 in stages covers the path most legacy projects actually need to take, and it is worth sharing with a candidate to see how they react. Someone who nods along and starts asking about your specific bundle list is further ahead than someone who assumes every Symfony app can be upgraded the same way.

Doctrine migrations tell you more than a CV does

Few things expose real Symfony experience faster than a conversation about Doctrine migrations. A legacy project rarely has a clean migration history. There are usually gaps where migrations were run manually and never recorded, schema changes made directly in production during an incident, or a migrations table that no longer matches reality.

Ask how the candidate would confirm that a project's actual database schema matches what the migration files claim it should be, and what they would do if it did not. A developer with real legacy experience will mention diffing the schema against the entity definitions, checking for orphaned migration files, and being cautious about running doctrine:migrations:migrate blindly on a database they do not fully trust yet. If the answer is simply "I would run the migrations," keep looking.

Testing habits reveal how they will treat your codebase

You are probably not inheriting a project with strong test coverage. That is normal for legacy Symfony applications, and a good freelance developer will not demand you pay for a full test suite before they touch anything. What matters is how they approach testing around the specific area they need to change.

Ask what they do before modifying a piece of untested legacy code. The honest, experienced answer usually involves writing characterization tests first: tests that document what the code currently does, bugs included, so that a change can be verified against known behavior rather than guessed at. If a candidate says they would just refactor carefully and test manually in a legacy PHP application with real customers on it, that is a risk you should weigh carefully before signing anything.

Questions worth asking on the first call

A short list of direct questions can save you weeks of pain later.

• Walk me through the oldest Symfony project you have worked on and what version it started on.
• How do you confirm a legacy database schema actually matches the Doctrine entities before making changes?
• What is your process for adding tests to code that has none, on a project already in production?
• Have you ever had to roll back a deployment on a legacy system, and what went wrong?
• How do you decide what to leave alone versus what needs fixing right away?

The answers matter less than how specific they are. Vague, general answers usually mean the candidate has not actually lived through the situation you are hiring them to handle.

Red flags that should make you pause

A few patterns tend to predict trouble on a legacy Symfony engagement:

• Eagerness to rewrite large parts of the application before fully understanding why it was built that way.
• No questions about your current PHP and Symfony version, or your hosting and deployment setup, before quoting a price.
• Confidence that feels disconnected from the complexity you have already described to them.
• No mention of backups, staging environments, or rollback plans when you ask how they would approach the first few weeks.

None of these are automatic disqualifiers on their own. Together, they tell you whether someone has actually done this work before or is learning on your production system.

What this should cost, and why the cheapest bid is rarely the safest

Rates for freelance Symfony developers vary widely, and the lowest quote usually costs more in the end once you factor in what happens if the engagement goes badly on a system you cannot afford to have down. A developer who has genuinely worked on legacy Symfony before will usually ask for time to explore the codebase before giving you a fixed quote, because estimating unfamiliar legacy work accurately before looking at it is close to guesswork. Be wary of anyone who quotes a firm price and timeline from a job description alone, without having seen a line of your code or asked about your database size, your traffic patterns, or what else runs alongside the Symfony application.

A short paid discovery phase, even a day or two, is a reasonable ask and a good filter in itself. It gives the developer a real look at your codebase before committing to a number, and it gives you a low-risk way to see how they work before handing them the keys to something the business depends on.

Getting this hire right

A legacy Symfony codebase is usually running something the business depends on, which is exactly why the wrong hire is expensive. The right freelance developer treats your existing code with respect even when they privately think parts of it should be rebuilt, and they can tell you clearly what they changed, why, and how they verified it still worked. Our legacy code optimisation service exists for the version of this problem that goes beyond a single freelance engagement, when the codebase needs a structured recovery plan rather than one more pair of hands.

If you want a second opinion before you sign a contract with a candidate, or want help scoping what a legacy Symfony engagement should actually include, get in touch at hello@wolf-tech.io or visit wolf-tech.io. A short conversation about your specific codebase is free, and it usually surfaces the questions you should be asking that this post did not cover.