Preparing a Project Server migration: inventory first
A successful migration starts well before the data transfer. It starts with an inventory: what exists, what is still used, and what you leave behind.
Portfolio · Customer projects
Changing tools makes you want to move fast: export, import, and move on. That is how years of abandoned projects, useless fields and patched-up templates end up in the new tool.
List what exists
A Project Server environment holds far more than schedules: finished and ongoing projects, custom fields, project templates, views, and timesheet history. Each item deserves a decision.
Decide project by project
In our example, four projects are in the portfolio. The line relocation, the workshop extension study and the packaging line installation are ongoing: they migrate, with their actual dates. The overhead crane replacement is finished: it is archived, readable but not migrated.
Sort the rest
- custom fields: keep only those that support a decision;
- project templates: clean them before reusing them;
- timesheet history: export and keep it, even if it does not migrate.
Involve the people who use the tool
The inventory is not done in the database alone. Project managers know which fields they really fill in, and which reports they read. An hour with them saves weeks of pointless migration.
That is often where we start a migration preparation: an analysis of the environment, then a clear list of what moves, what gets archived, and what stops.