On a migration project, you sometimes come across a system that’s been around for a long time, does a pretty small task and hasn’t been touched in years. The question that arrises is “Should it be migrated to the new platform?”

Now. You could solve this problem by phoning up stakeholders and try to find someone who is actually using it. You could read the documentation… You could try and find the documentation in order to read it. You could even attempt to monitor the flow of traffic on the system to determine usage.

I say, forget all that time wasting due diligence . The best way to determine if a system should be migrated should be based on the number of complaints that occur when you shut it off.

If the number is above, say 5, you’ve found a system still in use and needs migration. You should also be aware that you may have to filter your number of complainants. You could snare some poor support guy monitoring general server heath. He’s just following his checklist, doesn’t count. If you land up snagging a VP (or better) complainer who questions why the system is down, you can just mutter something about the flux capacitor needed to be re-ionized and not worry about the method of your madness being questioned (VP: “Oh yes, the fax appropriator.. of course”).

If no one complains, you’ve just performed the fastest migration project in the history of IT.

Pat yourself on the back.