Migrating a system should always consider as harmful as making decision to marry a woman/man. The transition in between must be a continued process that planned carefully. Making the wrong decision makes the system and the organization rendered useless. Making general assumption about the system migration also the culprit of series of unfortunate events after.

To take a smooth system migration, there are things that need to be considered:

  1. The user of the system.
  2. Other system that depends on it
  3. Business process handled by this system
  4. Business process affected by this system

User of the system considered as one of the thing that we should ever consider. The trust between the system and user is built as a requirement to make the user use the system. Breaking any functionality in system can break user’s trust. Uninformed user can be a big threat that can take the system down. One viral marketing of badmouthing can take not only the system alone, but also the organization down — take a look at Omni Hospital case. That’s why, even free service providers such as Google, Facebook and Yahoo! take very long path to ensure that majority of users informed and adapted.

A better study how people would resists change is KDE system. When the version 4.0 released (the first KDE4 series), many of the users were pissed. Many functions were not there. The system was half baked and it was a bad decision from the beginning to release it immediately. Fortunately, KDE developers do an amazing thing: fast pace evolution of KDE4. Introduction of new functions, clear state of direction of the new system, and the release often philosophy attract new users while buy back the heart of discontents. They works at full speed with innovation and notify people really often while trying to step away from trolls. Communication and fast pace development truly marks them as a good innovator.

Another factor that would lead you to disaster if a system is a part of chain of systems. In software worlds there existed many terms for dependencies. The famous one is called API (Application Programming Interface). According to [WIKI], an API

is a set of routines, data structures, object classes and/or protocols provided by libraries and/or operating system services in order to support the building of applications.

This means each of shared library provide standard ways for other to access their functionality. With the encapsulation, complexity and obfuscation, people certainly cannot follow of each library they use and that’s the reason from the beginning why we love to reuse. Imagine if your system is a part of a bigger system, which is a normal thing in enterprise. Any change in your interface for other system to use (API) will make all of the systems that depends on that particular functionality fail. If the system you are changing is a core system, then it would cause halt on most of the systems, i.e. you’re screwed!

To tackle such devastation, any change to a function should be accompanied with fallback and backward compability. The most commonly used trick to do this is to deprecating such function. Deprecation is a form of noticing the user (in this case is the other system that consume your function) that the function is being shut down so they would expect no more of this function in future.

The real question of this is, when should you put off permanently of a deprecated function?

Software developers use major and minor number to differentiate versions of their product. Each major number indicating very big gap which make significant gap and even incompatible for each other. Minor number is indicating that the internal coding is change but still maintain compability. That’s why, version 1.0 can be compatible with version 1.1 but version 1.1 obviously expects things to break with version 2.0.

Of course, real life is not that perfect. Sometimes, you would have to shut a function immediately because of the security issue it implies. But, you can be like Microsoft maintaining the whole API more than 10 years or like Linux kernel which breaks ABI in every several minor version.

This blog content is getting like a book. So, I should stop here (you get the idea).

REFERENCE: [WIKI] Wikipedia. Application Programming Interface. http://en.wikipedia.org/wiki/Api (Accessed at Thursday 13 August 2009)