An Expansive View of Migration

I've had the chance to express my views on application migration a few times over the last month - it's a complex subject.  I think of it in a pretty broad way, the diagram below which I created a little while back now expresses this well...

This is a broad view of what needs to be done - I should do a few posts to explain the various aspects - but I'll start with a short one here... It is worth stating that in many, many scenarios you don't need to think this broadly. 

Sometimes life is very simple.... Other times it is not...

When I think of application/system migration I have three mantras in mind:

1. My preferred strategy for a large application is to surround and conquer, i.e. build the required skills on loosely coupled segments of the application and re-develop these.  As you do this you get better at understanding the issues and potential of the new platform.
2. If your application is extremely tightly coupled (lots of copy and paste, lots of assumed interfaces) - then you need to get over it and just rebuild it.  Don't kid yourself, you will spend more time dissecting it than improving it!
3. Application porting (via tools) is a great way to go - if and only if ... you don't hope to extend the application significantly over time i.e. porting won't address the differences between O-O and Procedural models.  Porting only replicates the mistakes of the past!

Also don't forget different layers in an application need to be treated in different ways e.g. if you do a phased migration of the business and presentation layers while a system stays running, it's unlikely that you will alter/touch the data layer/schema (the curent system is afterall altering it every day...) and as a result that same layer will very likely become a constrinant moving forward when you want to redesign/refactor the system.

I've got plenty more to say here - but I'll save it for another post....

My last statement on this post is that migration is required (in my mind) where you are on a non-modern language or platform and still want to progress. 

Modern API's offer so much that it's very hard to walk away from them (OO, Web Services, AJAX, ...). If you are happy to stay where you are (functionally and interface wise) then consider porting the application.  But at the same time you need to realize staying where you are will 'turn off' the best developers and eventually you will need to move if you hope to grow.

People think migration is no fun, but remember migration is about application modernization - a time for the applicaiton to lift it's game, a time to impress it's users!  Migration, if well done delivers business benefits and cost savings... If this is not the case why else would you do it?