Migration of Requirements Versus Greenfield

Every now and then a business manager has to ask himself whether to continue with his current processes, or start allover again. So it is appropriate to provide some information on this subject.

Advantages and Disadvantages Of Greenfield and Migration Strategies

Viable questions with this regard are issues like:

  • What are we going to do with our current legacy infrastructure?
  • What are we going to do with are current legacy technology?
  • And what are going to do with our current employees?

These are examples of questions easy to ask, and difficult to answer. Yet we all know that we need an answer before we can decide on how to proceed. This implies that we need a process that can supply us with the answer after executing some steps. We recommend to this by crafting a business case, and evaluate this before proceeding any further.

There are questions to ask at project startup:

  • Can we reuse the existing specifications, or should we start from the very beginning?
  • Can we migrate the content of the dictionary of our old tool to the new tool and environment?
  • Can we reuse our existing methods, or must we adapt new ways of working?

Generally speaking: it is possible to migrate from old to new. The question is rather is it worth the trouble? And more precise: can we create a requirements planning business case for the migration?

Input for the Migration Business Case

The important question to answer before we can establish a successful and positive business case is: What does it take us to make all required knowledge explicit, that is:

  • Administrate the specifications in a dedicated tool.
  • Run automated checks on the specifications in order to validate the consistency and plausibility of the contents.
  • Throw away everything which is flagged as not directly usable.
  • Execute one or more business requirements gathering workshops in order to complement the kernel specifications and to enhance them so they reach some level of usefulness.

The Business Requirements Business Case

Having all those activities done then you have your migrated specifications. This is a lot of work, and usually not much less then starting all-over. So if you do have a lot of material in a repository then it is best to do a small experiment for a week and find out what the result is. That is very good approach to gather metrics for an estimation what a complete migration could cost.

Usually it is better to stay on the safe side, and take all your documentation with you in the workshop, and use it there and than as input. This is what you could call 'a logical migration', and not a physical.

Such a business case is not really different from a 'greenfield' business case, and guarantees that:

  • All business knowledge is made explicit, and therefore independent of persons.
  • All business knowledge is extracted from all tools, so the licenses can be stopped (and cuts costs).
  • Existing approaches are reformed to the new way of working by a training on the job on trusted and known specifications.

Usually this is the best way to migrate from old to new.

back to top