Pitfalls of the DIY Project Online Migration Using FluentBooks
When choosing DIY migration with FluentPro FluentBooks, you should pay attention to common pitfalls that make the entire migration process flawless only on paper. A typical system has been operating for 5–20 years. Over the years, changes in it have been documented by various departments and contractors. Each with its bell tower. There is no more integrity in the documentation if there ever were. Nobody fully understands the logic and structure of data storage. A special case of documentation is in regulations and descriptions of business processes: how data gets into the system, under what circumstances, in what format. All this does not help either.
Project Server or Project Online migration is usually considered a routine in its activity. Most organizations migrate data regularly. However, there is nothing predictable about data migration. Mostly because plenty of issues appear out of nowhere when migration is considered and executed purely as “a routine activity.” Many of DIY data migrations either fail or break your budgets and schedules. How can you avoid or minimize the risk of being part of those who fail? The answer is simple, first, stop considering migrations a one-day job. Prepare and consider a combination of different aspects that need to be factored in and managed in advance. By learning about common pitfalls and addressing them properly, you will save yourself from painful and inefficient data migration project.
Also known as “insufficient planning and not notifying users that migration is in progress” is the most common misconception about data migration. Many consider migration a purely technical task, which usually leads to a logical, yet a completely wrong purely technical solution. Yes, the extraction, transformation, load, and testing are all technical jobs. Nevertheless, there are many other affairs within the migration process that require the non-technical approaches. For example, input from the owners of that information, identification of the correct sources, clearing out the useless, repeated or unneeded data, etc. is a strategic task, and it requires non-technical approach.
Data migration is not always a straightforward process even within a small environment; therefore, as any project, it requires planning and engagement of users on different levels. Notifying users about migration “coming” and requesting to modify as few projects plans as possible allows to lower the number of project plans for delta migration* dramatically. The more project plans are modified during the production migration, the longer delta migration will take, delaying the go-live date.
Migrate First, Test Later
Sadly, skipping test migration means testing the individual components of migration is postponed, delayed, or skipped completely. Nevertheless, having a data testing strategy “on-hand” gives your team a better understanding of the acceptance criteria and the desired outcome. The very purpose of the test migration is to identify specific issues and either resolve them before proceeding with the production stage or create a mitigation plan. If the test migration is skipped, then any issues that arise will have to be resolved during the production migration when time is limited. This causes delays, unnecessary stress on the team that performs the migration and may lead to poor decisions. The duration of download and upload operations depends on the data and environment and can be accurately measured during the test migration. The knowledge about operations duration gained during the test migration makes planning of production migration more precise.
No Data Governance Strategy
If you involve all data stockholders are in data related decision-making, the team gets a clear set of guidelines to follow. This approach sums up to data governance strategy, which is very helpful in any project implementation, yet is often “thrown out the window.” More so, by creating a regulatory body on the early stages of migration will save you from risks like data duplication and provide “data homogenization.”
Clean up in the source environment before data migration is very useful and allows to eliminate migration scope and make sure that only the really necessary data is migrated, cleanup also helps to shorten the duration of migration. Clean up in the source environment during data migration brings additional effort and complications and may break the integrity of data, because the cleanup is done in between downloads of specific data chunks that are all co-dependent. For example, when the clean up is performed after only the PWA configuration and resources have been downloaded, this can cause complications when we start downloading Project Plans, because co-dependent data won’t add up.
Clean up in the Source environment during data migration on the contrary brings additional effort and complications during migration & verification and may break integrity of migrated data, if this clean up is done in between downloads of specific data chunks that are all co-dependent (e.g. clean up is done after PWA Configuration and Resource Pool download but before Project Plans download).
Lack of Experience With FluentBooks
Migration process consists of multiple steps that have to be done in a specific order. The migration tool provides various wizards, options and settings for different migration scenarios, it requires a certain expertise to use the tool efficiently. Test migration allows us to get the feeling of the migration tool and identify what settings need to be used in this specific migration scenario, what core steps need to be performed and identify any additional steps required to complete the migration successfully. The other way around is to choose managed Project Online migration services and rely on professionals.
No Data Versioning
When implementing an iterative approach, some people hurry to “get rid” of the previous version of the system. Though wrong, this is understandable. Why keep the older, less perfect version? However, when you keep, label, and version each iteration accordingly, you can reference back to a previous version any time it’s needed. This approach will help to troubleshoot all the processes help “test drive” your old ways against new or changed rules.
Data migration is an important endeavor. During the migration, you deal with the most crucial asset you’ve got – information. Done correctly, data migration initiative inevitably leads to transformative change, like changing the maturity level of your whole entity or finally getting complete visibility and control. There is no way to stress how crucial migration can become to the overall success of your business.
*Delta migration – the last phase of migration, requires freeze of source environment, during this phase project plans modified while production migration was in progress will be re-migrated.