So many times as people look to move to new servers, new solutions, new platforms, they’re faced with some fundamental design points. These include:
– Time allocated to make the change
– Code review
– Functionality review
Taken together, these are big deal items. They take time, they take resources, but most importantly of all perhaps, they’re actually easy to ignore and work around.
So many times that first one takes it’s toll on the migration. It doesn’t matter if you’re moving to a new server, to a mixed environment, or what the direction is, time is always an important factor,
It’s critical though that you allocate the time you have available to review the architecture, the code, the approach to the application. Too many times we have to retrofit applications and solutions to new technology environments – and that retrofit is incredibly dangerous.
At sswug, as we have moved servers and archtiecture over the years, we’ve been constantly faced with reviewing the code, the approach and the underlying tecnologies used to bring you the site and services. We’ve made some good choices to retain code at times, and we’ve made mistakes of course. But looking back, I’d say it’s been very important to review and consider functionality with respect to the environment we’re moving to.
It’s not a simple thing to move. Many times, just the process of moving will take so many resources it’s hard to imagine tossing other responsibilities on the fire that include code reviews and architecture. But I can tell you from first hand experience, and from those of customers we’ve worked with, that making certain you do those reviews can make a huge difference.
The default action is to just move the world. Move storage, processing, access rights. But this can be hugely tough on your applications, and can leave you holding the bag on some of the best functional improvements (speed, operations, etc.) that are available from the move.
I completely understand that there are times when an expeditious move is paramount. It simply takes all priority. It has to to address a failed system or a functional flaw or whatever. But in other times where you have a bit more control, be careful to make sure you’re not moving things from one environment to another …
“Just because we’ve always done it that way…”