A Strategy for an Unmovable Legacy Architecture

“How do I follow best practices when re-architecting my legacy project?”

It’s not uncommon to have a project built with ASP Classic or VB6 lurking around in your enterprise.

Sometimes, enough service requests come up that you have to think about upgrading that monolith. Maintenance costs outweigh the costs to rewrite the app into something more supportable.

You may be able to keep your high-profile projects on modern architectures like ASP.NET MVC 2, then 3, then 4, then 5… but good luck with that VB6 app!

What do you do when you’re faced with a legacy codebase, and all you want is the model-driven, tested, single-responsibility goodness of your fancy shmancy MVC project?

Think about change.

When I’m planning architectural refactorings to an application, be it a legacy app or a somewhat modern app, I keep one phrase in mind: “anticipate change”

The sales director, plant managers, mechanics, salespeople can all be loud enough to get a change request thrown their way e.g. add a field, filter a grid, new facility opens up, new product released…

”…Remember the old engineering adage: ‘if it ain’t broke, don’t fix it.’ The program may not be broken, but it does hurt. It is making your life more difficult because you find it hard to make the changes your users want…” - Martin Fowler, Refactoring

While Fowler was talking about refactoring efforts, re-architecting and modernizing can be thought of as a series of refactorings. The anticipation of change still applies.

Here’s an example:

• You’re getting a ton of requests about bugs in a VB6 app
• The app has much potential for domain entities to be extracted: repositories, factories, services, unit tests, dependency injection, you name it…
• The app happens to deal with products your business sells
• The business is constantly developing and releasing NEW products
• The business is very likely going to ask you to add NEW products to the app

You can focus your strategy on being smart and following best practices as you anticipate changes to the domain entity: product. You can begin layering the application around this vertical slice, introducing a data access layer and a repository layer for managing products.

Staying within a vertical slice that will get a lot of change lets you stay rooted in making important refactorings before getting overwhelmed or stuck on a framework/solution.