Change is constant. Evolution has always pushed us to migrate to a more assured state. You don’t have to be Darwin to realize that software development is no different in this regard. Migration becomes all the more relevant in the Enterprise CMS space when looking at the rapid pace of development driven by new requirements that concepts like content intelligence create.
The case for migration is further strengthened in light of the shifting Enterprise CMS Vendor landscape, which has been witness to a high level of consolidation in the last few years. The total to be spent on data migration has been projected to be roughly US$ 8 billion in the coming year and considering that more than 80% of data is unstructured, the Enterprise CMS migration market will be blossoming. In this article, I am going to share my experiences on how to plan and execute an ECM migration project.
Why Do We Need a Change?
Each migration is different and has a different motivation. Half of the battle is knowing why the migration is taking place. I have seen many projects spiral out of control when the executing team has no clear idea why the migration is being done. So the first rule is to establish what needs to change and why. This not only helps in defining the scope for the migration, but also helps in defining the correct platform and roadmap for the migration implementation.
For example, a migration exercise which is a result of a compliance change generally comes with firm scheduling constraints, which will influence many decisions. Whereas if the driving force is productivity gain, there has to be a lot of internal stakeholder participation required for re-platforming. If increase in the market share is the main driver for the enterprise, the migration should be preceded by an in-depth quantitative study of what the specific goals are. Another important and sometimes ignored aspect is understanding if platform migration will resolve your problems or if a change to the workflow is necessary.
Upgrade vs. Migration?
The next big hurdle is making the choice of whether to upgrade your platform or to migrate out of your current implementation. This choice becomes even more complicated if the size of implementation is big and the stakeholders affected are large in number. For one of my assignments migrating from Lotus Notes to SharePoint, the decision to migrate came only after many upgrade exercises to bring the employees, who all used Lotus Applications, up to speed.
While an upgrade is generally much less expensive and can be done in-line if required, it is important to gauge what is the roadmap of your current vendor. An upgrade should be a substitute for migration, not a way to procrastinate the inevitable. My recommendation here is to do a product selection exercise and let your incumbent participate as an equal competitor without thinking of whatever additional effort this might require.
Supermarket vs. Street Vendor Approach
A synonym associated with migration is consolidation. We have to be careful that we are focusing on consolidating our platform and not consolidating our problems on the new platform. Sometimes our thoughts and hence our actions are too linear and we miss out on lucrative opportunities.
My recommendation is to remember that we do not have to take everything from point A to point B. There can be multiple small solutions and quick wins which we can build fast to meet our needs. For example, at the heart of every migration is data, and there has to be a proper plan around how this would be migrated. A detailed study of the current repositories, including dependency analysis and usage pattern (using the ECU model), helps to determine the best-path solution that results in a much safer and faster migration.
What Do I Need to Migrate?
The next step in our migration roadmap (and probably the most important one) is to decide what needs to migrate. A lot of important decisions are made here that may have a lasting effect on the whole migration project. The classic dilemma is to justify an apple to apple migration vs. a rebuild on the basis of current requirements. This problem is further compounded by the possible feature gap between the new platform and the old one, which may have been a driving factor in the push to migrate.
Idealists would say that migration is an opportunity to build what we want rather than what there is. But this is easier said than done. A lot can go wrong and probably will go wrong if we try to kill too many birds with one stone. As per a study, only 16% of migration projects are on time and within budget. Scope creep is the main cause of project derailment.
In one ECM migration project from a legacy system to a modern J2EE based platform, an attempt was made to rationalize the applications and then move ahead. The project soon became complicated beyond recovery; as a result we had to retrace our path back. My recommendation would be to take a staggered approach. Phase 1 should concentrate on "as is." When I say "as is," I do not mean identical twins, there will be differences, but the emphasis should be on the functional specifications to be as close to those that currently exist.
You can cut some undesired fat if you want to be creative, but avoid the temptation to add new functionalities. At the same time you should always look at ways to leverage the OOTB features of the new product. It is equally important to keep the stakeholders engaged by taking a view of their current needs and expectations, and propose a firm plan (Phase 2) to roll out the resultant functionalities.
How Do We Approach Migration?
Last but not least, how do we carry the entire migration piece? Most of the ECM migration initiatives in my experience have been IT funded, so there is an inclination to carry it along with business as usual activities. I think this is a cardinal error. Migration should always be treated as a project. Having said that, we have to realize that even though we are developing afresh, it is not development from scratch. There will be a requirement phase, but the nature and the level of documentation accompanying it should be on a best effort basis. More focus should be given on prototyping rather than the functional specs, as this will also help in early change management. Similarly, I recommend taking a risk based testing approach rather than a waterfall model based approach.
This article has just touched the tip of the ice-berg of ECM migration. There is a lot more to be said in terms of common tools, techniques and scenarios and there are more decisions to make in terms of hardware refresh, parallel run, skill upgrade (as ECM implementations are predominantly COTS based), etc. Watch this space for more on migration related recommendations.
Editor's Note: You may also be interested in reading: