Rearchitect or Rewrite

I've been doing a lot of work recently on putting together the proper way to upgrade our current system. Let's start with the basics, our current system is written almost entirely in Classic ASP VBScript with a Sql Server 2005 backend. It's a multi-tenant, multi-usertype, multi-lots of different things just all baked into one BBOM¹. We have a couple 200+ line stored procedures, a couple of 2k+ line scripts, no consistent ux patterns, etc. The list goes on, and is probably the perfect example of an architecture that might have been good at one point in history, but has been replaced by countless things, some of which have probably already themselves been replaced. I do give credit in some places, our schema is not too bad, and has handled most of the things thrown at it. Because of this, we haven't really seen many of the problems that are associated with giant architectures, it is still fairly fast, we don't have many deadlocks, and other pain points are relatively non-existent. That though, is about the extent of the good.

All of this is in a desperate need of an upgrade, new architecture, something. There are a lot of people that advocate never throwing things away. It's all about refactoring and replacing things piece by piece until you bring the entire system into a state that it should be in. This is something I really struggle with attempting. If we assume that our target is a .Net system with a web front-end targeting Asp.Net MVC 3 and a services layer running between that and our data stores, we should be able to already see the problems. For starters, we have a script (single-page) based system that needs to be converted to model-view-controller² based awesome-ness. Then we have a non-existent services layer that we could write first, and upgrade our ASP scripts that we are going to delete at some point to use said service layer. There is an option of using .Net COM objects in our scripts, but again, the scripts needs to be deleted at some point and the COM objects are likely to be so heavily tailored to the scripts that there is no reuse possible with them. Another problem we have is a ton of business logic that exists inside of the scripts, and inside of stored procedures3. This exposes a serious issue with testing. We lack any ability to have all of our tests in a central place. Some of them involve testing scripts, some involve testing stored procedures, and even more involve testing a combination of both. This is just for our business logic, testing the functionality of different pieces, be it a web form or service, is going to have that problem already, I just wish we had a more concise place to test our logic and use cases. Even though it is considerably easier to overcome, we also have a problem with some different 3rd party components. These seem to not play very well at all with Server 2008 and IIS7. The process to fix those would probably involve finding equivalent components that work with Server 2008 and IIS7, then rewriting the ASP parts to use those new components. Then rewriting it again to get it to work with whatever XYZ architecture we refactor to.

After a long time of thinking and working, I think I am of the opinion that refactoring is not the way for us to go. Had we kept up with current technologies, this might be the way to do it, but I feel like we are no longer in a position to easily complete it. For starters, we are going from a scripted environment to an OOP-compiled-static-buzzword environment. Also, as stated before, our services layer is, well, TBD. I think it would be nonsensical to write it in a way that benefits the current site, but might not have any benefits to whatever we completely move to. Even more to the point, we really want to delete a lot of stuff. All of the stored procedures lack a good refactor path.

There seems to be 1 more thing added to the reasons to rewrite every time. It is as if there is a calling from the code to not even try to mess with a refactor.

Notes:

1. Big Ball of Mud
2. model-view-controller
3. I don't want to talk about how bad it is having business logic in stored procedures is, I will just leave it with they are impossible to test without using integration tests (read: slow).