At what year you start considering code as legacy code. What about 2006!

Imho its about the kind of code, not only the age.
I would consider a recently written COBOL application wich uses existing ISAM files as legacy right from the beginning.
A old well written C++ application wouldn't necessarily be a legacy app in my eyes.

if the software is deprecated more than 2 years. I know some folks still use compass for sass, also same with bower, bundler and angularjs. this is not really legacy like cobol, but no one will use those i mentioned when setting up new project.

Untested code = legacy code

Anything not actively maintained if it is not 100% documented and tested.

6 months old JS code is probably legacy if it's not using newest nextBigFrameworkThatYourCodeMustUseOrItsShitCancer

Age is an arbitrary metric, with no actual connection to the question at hand.

@EdoPhoenix At my work those two not always go together. We maintain a system where the company behind the language and compiler no longer exists

Simple. Any code: as soon as it gets deployed to any customer machine.

To address some of these questions. It has some integration tests, had to add unit tests. I would expect some modern patterns like, services, transformations, dao objects etc. Instead the structure is modules using subclassing hierarchy, with a few interfaces. The method naming convention did improve in the last year or so. While , many variables are still using five letter acronyms, comments etc .

At my recent internship, the product had started being built in about 2000.
That said, it's been well maintained and upgraded over time as much as possible and as safely as possible. And it's still in use across the US.
Kind of funny though working on maintaining something you remember using in 2nd grade.

If you have 2 or more code bases in production that aim to achieve similar functions, the one you want to die the most is legacy.