Defining and testing migration rules

Well, it's not too late yet so: Happy New Year!

Today I want to tell you about migration rules and how to automate them.
When dealing with migration projects, we apply a process determined to best suit its context.
Though each project is particular, some things never change. For example, we define migration rules, and this is actually an important part of every automated migration project.

What is a migration rule?
It's the specification of what one wants to get in the target architecture from a given concept present in the original architecture.
In migration project, such rules are automated whenever it makes sense, assuming that it is feasible (actually, determining what is feasible is a whole subject in itself, but that's another story).
As any artifact in a development process, a migration rule must be:

• specified
• tested (which assumes it must be testable)
• implemented

Moreover, non-regression testing is extremely important in this kind of project. Migration rules have a nasty way of interacting with each others, and it's utterly important to be able to check that the modification of a rule does not impact another. We want to make sure we have the whole migration process under control.

Finally, reporting is important as well. You want to know which rules have been applied, how many times, and where: such a feedback is precious once again to make sure the process is under control.

So? So, we're currently developing some tooling to help us achieve this. In a few words, we're (partly) automating the process we used to apply manually until now.

This tooling will allow us to specify, implement, test, ensure non-regression, and report about the execution of the rules developed in a migration project.

More details and screenshots soon!