3 Signs Your Project is Becoming Legacy and How to Avoid Them

Taking care of a software project long-term is not about immediate action but routine and regular checks.

We have to know we're heading in the right direction; otherwise, we might end up trapped in a legacy project that is hard to get out of.

When clients contact our Rector team for help with their project, they often share a few common treats. I wish they would contact me 2 years earlier for a week of consulting. Their project would be in a much better shape.

Based on experience with 100+ legacy projects, I can see what decisions will result in long term positive results and what will take your project astray.

This will be a 4 post series, and we're kicking off with why this matters.

Can you Decide?


This post is for you, and its goal is to make your project healthy so you will never need our help with upgrades in the future.

Check Routinely to Stay on Track

Imagine you ride a boat in the sea. You want to get home about one hour away. At the start, you set the course based on information at the port and sail off. If all the conditions are perfect and still, you're home in an hour.

"Change is the only constant".

But life is everything, but still. The wind might change, and the current might change, too.

If you stay on the same course, you'll end up far away from home in nowhere.

People who sail ships know this and check current + wind direction and counter their forces accordingly to keep the original course. We revise the course every few minutes to get home as fast as possible.


We should apply the same routine checks on software projects. We should check if we're heading in the right direction; if not, we should change it.

Avoid Sunk-Cost Fallacy

The sunk-cost fallacy is like continuing to fix an old car you've spent a lot of money and time on, even when it's clear it will never run well. It's the "I've already put so much into it, I can't stop now" mindset, even if stopping is the wiser choice.

Let's say you implemented your custom PHP framework and run 10 projects on top of it. You already know its cheaper and easier to use Symfony or Laravel for past 5 years. You actually use those on your own projects, but your company has already invested so much time and money into that "custom framework" it that they can't stop now.

If that's your case, stop now, as it will only worsen.

Decide and Evaluate

Nowadays, flipping a framework is a matter of months of work and will only become easier. Nobody knows the future and we can't wait standing still for it to disclose itself. That's why it's essential to choose a package, a technology, or a framework and evaluate, e.g., once a year, if it's still the right choice.

If you feel it's not the right choice, you've learned something new. Move on and change it.

Do It!

Do you know Art Williams?

He made a fortune in the insurance business and has a great, funny speech (20 min) about how to succeed. It's not exclusively about business, but about life, family, or working on long-term projects.

"Art, if I could just sell my house." Do it.
"But houses ain't selling?" Do it anyway.



At Rector team, we help our clients to get the most out of their existing codebase, team and market position. Why do our clients hire us? Because we know how to run Rector in CLI?

No, we have the same technology as everyone else. But we put 100 % focus on one goal.

Our client hired us because we are fully dedicated to face the unknown challenge. Our only goal is to keep improving the project, until it's in the best shape possible to that date.

And we keep doing it until it's finished.


From Decision to Hard Work

This post was about making decisions, committing, and working hard to improve your project.

In the following posts, I'll share 3 of those choices that went too far and how to eliminate them with smart thinking and hard work.


Happy coding!



Do you learn from my contents or use open-souce packages like Rector every day?
Consider supporting it on GitHub Sponsors. I'd really appreciate it!