When your system looks like a knackered Vauxhall Cavalier, it's time to change...
Upgrading to a new system is something I’ve only really had to get to grips with in the last few months. I normally spend my day-today working life either making minor website changes, developing completely new ideas that don’t tie into anything else, or maintaining our current systems, but never building new ones. This is pretty rare since the definition of being a software engineer alone carries the fact that most of the time you’ll be building a replacement system for something or other, even if the current system isn’t in any way computerised.
So, this article is going to detail my personal experiences with migrating from out-of-date systems. This means that it will contain a lot of opinions, some of which not everyone in the industry my agree with, and some points of view that may be fundamentally wrong. However, I’m not going to make any apology for this, this is just exactly how I see system migration, so it’s how I’ll tell it!
When is the Best Time to Start Building a New System?
The first problem is knowing when the time is right to sit down and start planning your new system. If the current system you’ve got isn’t throwing up any problems, and there aren’t any features you or your clients are gagging for, then I would suggest to stick with what you’ve got. However, if you’re finding that the bug and feature requests are piling up, and the system has either stopped making money, or worse, has become a money-pit, then it’s time to get out your pen and start drawing some mind maps. Bear in mind though, that you have to be able to justify the planning, development and migration costs that will be involved with a new system. If you can’t justify this to yourself, how are you going to justify it to your boss?
With regards to my experiences, we built the first incarnation of our system and turned most of it on in Summer 2008. For a long time, we were very happy with it, but it soon became apparent that a few little problems were going to re-appear as we continued to use the system, and when we identified a whole new side to the system that would be absolutely impossible to bolt-on to the current incarnation, it was time to sit down and start drawing up plans for version 2. When we built version 1, it was more than adequate for what we needed, but as ever, times change and new situations evolve that cause complications and mean that systems need re-evaluating…
Planning and Designing the New System
OK, so you’ve decided a new system is in the pipeline. Now, you need to sit down and design it, using the flaws and missing bits out of the current system as a foundation. One thing to remember is not to get hung-up on how the current system is designed, you want a version 2, not a version 1.01… The best way to help this process is to bring people on board who weren’t involved with the last system. These people will be able to provide a fully independent view of the problems that befell the last system, and how they see the problems as being fixed in the newer version. I know today’s software engineers are all about agile, but still try and plan as much as you can before beginning development. It’s one thing to start the first iteration of a build, and then to find out the plan was no good and start again, but how many times are your paymasters going to let you do that?
We used the first system’s design, or lack of it, as a basis to begin the design for the new system. This time we knew exactly what we wanted from it, so designing a framework and basic architecture wasn’t too demanding.
Development
I like tho think that the actual development of the new system is the easy bit, normally. If you’ve planned it well and know exactly what you want from the new build, then park yourself in front of an IDE and code away furiously until it’s done. Occasionally though, it isn’t that simple. Feature requirements will change throughout development, and you’ll need to be on your toes to keep up with the demands of your stakeholders!
Feature creep has been a major problem in the development of our new system, and we had to get to the eventual stage of saying “No more!” and admitting to developing them after the system has gone live. That’s the beauty of a web-based system, development doesn’t end with a final release, it just keeps going and going 
Testing: the Important Bit
I can’t stress enough how important testing is for a new system. However you decide to deploy it, everyone, and I mean EVERYONE, is going to expect it to work perfectly straight away. If it doesn’t, you’re in for a really hard time. Make sure you right the tests as you’re developing the system, it’s no good waiting till the end and planning the tests around the finished system, save that for the basic black-box tests. Test every function and feature as you’re adding it, and write unit tests that you can run every time you add something new, in case it breaks something old.
The Final Migration
Finally, your system is built! Rejoice! You’ve designed it, built it, and tested it within an inch of it’s life…
But now comes the hard part.
The way I’ve seen it so far in my short time on this world (even shorter as a developer!), there are two approaches to switching your systems over. Both ways have their advantages and disadvantages, and however you do it, something might inevitably go wrong, so I suggest weighing up the two options and choosing based on your current circumstances.
Approach One: Run Two Systems in Parallel
This method is the easiest from your point-of-view as a developer. You get to see any problems you’ve missed out in the new system, and improve on them as you go before the final switchover. The problem is that everyone who actually uses the system has an immediate doubling of their workload. They might not be too happy if it takes you a month to iron out all the bugs before you get the new system fully online by itself. If you go for this approach, make sure you only do it for a short period, otherwise you may end up having no work friends!
Approach Two: Complete Switchover
Although you may sweat blood with this approach, you should be fairly confident! You should’ve already tested the system thoroughly, all that remains is finding a suitable time to switch when the system is either not being used, or being used in a minimal fashion. The pitfalls of this method are bugs: if they creep up now AFTER you’ve switched over, they can cause a lot of misery.
You need to weigh up the two options and decide which one besets your position at this point, I can only provide the options, not make you choose
Update
Read Aidan Garnish’s comments below on his third method! A hybrid between the two that may just be the best for your situation!
One Comment
Great post Jamie! This topic is definitely a tricky one. In my opinion there is a third way to switch between systems that I have used fairly successfully in the past. Rather than switching everyone over to the new system just pick a small number of people. These are basically your beta testers but they are using the system for real in a live environment. This takes some of the pressure off as if something goes wrong only a small number of people are affected. Keep running like this untilyou are happy that most bugs are removed.