While there are many reasons for this migration, it is typically based on product end-of-life, erratic (too much or too little) functionality, commercial considerations, or a change in leadership. With so many factors involved, firms frequently seek outside help to ensure a smooth transition and migration.
Once the decision to change has been made, timing that change is the first critical parameter. Depending on the complexity, appetite for risk and number of projects, as well as when the change might occur during a project lifecycle, timing may involve a big bang cut-over, a phased cutover, or simply the initiation of new projects in the revamped system.
If an existing system has been employed for many years, the users will have opinions about system functionality and wish-lists for the anticipated changes in their improved system. The migration is an opportunity to engage these users and implement the new system to include as many of those requests as possible. An added benefit is the opportunity for the organization to make wholesale changes to their business model, from something minor like altering the workflow, such as how a form, document or pay request moves through the system, to something more fundamental. For example, an organization might be currently running their own server for their project management teams, and they might choose to procure their new service using software as a service (SAAS) model.
If an existing system has been employed for many years, the users will have opinions about system functionality and wish-lists for the anticipated changes in their improved system.
Moving to a SAAS model (for organizations that have hosted their own systems) often gives greater flexibility in the number of licenses procured. A SAAS model might allow an easy increase or decrease in the number of licenses used or allow a single-user license to be used across multiple instances of a solution. An example might be a contractor using their same license simultaneously across multiple owners’ systems. The migration could also allow other functionality such as offline access, or access from mobile devices, so staff can make updates without needing to be seated at a desk.
Data can of course only be migrated if there is access in the project management information systems, whether hosted locally or accessible via APIs or web services on a SAAS offering.
The difficulty of migrating data is directly related to how fully-configured the new environment is when the migration takes place and how much access is available to the underlying databases. To maintain data integrity during the migration, each element of data needs to have a 'home' in the new system so that inter-relationships between data are maintained during migration.
To maintain data integrity during the migration, each element of data needs to have a 'home' in the new system so that inter-relationships between data are maintained during migration.
A migration will be more successful if time is invested to clean up the data being migrated. For example, the same subcontractor might appear across several different projects as several different entities (perhaps because of a past input error), and it might be possible to merge those records to reflect the fact that it is the same organization.
Completing the migration
The final component of a successful migration is to ensure all users are trained and familiar with the system. By keeping those users whose feedback was sought prior to migration involved in the testing, those same users are able to train themselves in the new system and can act as internal experts for everyone else.
The migration project doesn’t finish when the system goes live. There will always be minor changes, though every organization is unique and each must decide the cut point between the data migration project and maintenance of the new project management information system.