The one-time movement of content from one repository to another.
Usually as the result of a publishing platform switch, a content migration is necessary to continue working with and publishing existing content on a new platform.
When organizations change content management systems, the content in old systems must be moved into new systems. In the simplest scenario, this is a direct transfer from one repository to another. However, this “simple” operation usually opens up complicated questions about what content is moving, how the content must change, and how it will support the same level of functionality in the new system.
Content migrations are preceded by a comprehensive content inventory and an editorial process to determine which content can be discarded and which must be migrated.
Most migrations also have a development component, where technical decisions must be made on how content will function in a new environment—for example, how properties map from one system to another, how links are maintained, and how navigation is preserved.
In particular, migrating content that is interlinked to other content, either through explicit links or spatial positioning, can be difficult because the content, its relationships, and its position in the larger content structure must be preserved. This is complicated by the common reality that the two systems might have fundamentally different paradigms of content organization.
A content migration project invariably culminates in a “content freeze,” where no changes can be made to content in the old system until it has been quality checked and launched in its new environment.
The time and budget required for content migrations are often either completely overlooked or underestimated. Managing a migration process is a complex combination of technical, organizational, schedule, budget, and human processes.