1. The Milestone of Migration

2. The Nature of Content

3. The Challenge of Content Migration

4. Content Migration Precursors

5. Define Business Scope

6. Declare Business Success Criteria

7. Define Technical Scope

8. Declare Technical Success Criteria

9. Identify Necessary Transformations

10. Consider Discretionary Content Cleanup and Enrichment

11. Develop the Content Migration System

12. Embed Migration-Specific Metadata

13. Consider Repetition and Repurposability

14. Handle Edge Cases and Limit Manual Data Entry

15. Consider Virtual Content Migration

16. Prepare the Migration Manifest

17. Conduct Pre-Production Migration Testing

18. Protect Migrated Content in Its New Home

19. Determine the Timing of the Production Migration

20. Coordinate Content Operations and Interim Content Maintenance

21. Execute the Production Migration

22. Manage Redirections

23. Retire Legacy Administration Systems

24. Determine the Disposition of Source Content

25. Migrate, Iterate

Content migration achieves a milestone in the launch of a site or channel, the evolution of a Web property, or the release of a feature – as an infusion of fresh content extends new information to users and expands an organization’s online presence.

Planning an efficient and impactful migration requires that business, product and development teams accurately gauge scope and success criteria, carefully evaluate detailed technical intersections, and formulate a nuanced execution strategy. 

A successful content migration entails significant time, expense and engineering – but opens avenues to enrich content, streamline its delivery and illuminate its display. With proper focus, discipline and preparation, your migration planning will yield lasting value.

As a content professional, you work with content daily, whether creating it, processing it, or finding new ways to organize and present it. Now, consider the nature of content stored in your systems and repositories.

Content certainly includes HTML, text, pages, documents, files, images, media and other assets – but recognize that significant additional worth is instilled in a content set across its accompanying taxonomy and metadata values, semantic associations, structural interrelations, language versions, aggregations, naming conventions, stylesheets, formatting, encoding and redirections.

Even beyond its essence as informational material described by various attributes and classifications, content resides in layers of supporting technologies that bring it fully to life: administration systems, publishing platforms, microservices, APIs, messaging queues, databases, content delivery networks, caching solutions and front-end frameworks – all interwoven by custom development.

This array of juxtaposed content aspects means that a content migration must transcend the rudimentary scripting of relocation steps, or the painless uploading of comma-separated value files through a helper module, or the elementary batch porting of files from one file system to another.

Appreciate that migration also embodies tortuous data and format normalization, traversal of convoluted information architecture, meticulous reconstruction of intricate connections among content objects, extraction of delicate markup, retention of opaque taxonomy and metadata values, and painstaking validations across potentially hundreds of test rounds.

Along the way, a migration system must negotiate the sprawling maze of a bustling content ecosystem and reach into the many technologies engaged in managing the content lifecycle. Confronted with this challenge, a migration can inspire creative technical solutions, the cleanup of inherited disorder, and even the enrichment of a forthcoming content set.

Planning a content migration and developing a migration system presumes you have accomplished three fundamental steps somewhere in the context of a project timeline, product roadmap or release plan:

• Inventory: Performing a content inventory, in which you methodically uncover and index items in a content set, along with capturing a minimal amount of metadata.

• Audit: Conducting a content audit, in which you supply comprehensive taxonomy and metadata values and categorically assess the characteristics and fate of items in the content inventory.

• Modeling: Defining the content model into which content will be migrated and later authored, using content objects, metadata schemas and uniform terminology and structures.

With these precursors fulfilled, you will be able to encapsulate the candidate content set that needs to be migrated, as well as develop the migration system that will capture, transform and package source content and transition it into the target system. 

Based on the goals of your project and the phases in your product roadmap, define the business purposes that are served by a migration, for example:

1. Site or Channel

   1. new site or channel

   2. redesign of an existing site or channel

   3. evolution of an existing site or channel

   4. consolidation of multiple Web properties

2. Feature

   1. new search categories or other search facets

   2. new dynamic aggregations of content

   3. new landing pages, navigation routes and menu options

3. Content Reconfiguration

   1. institution of new relationships among content

   2. separation of content into other content types

   3. combination of content into other content types

4. Content Optimization

   1. addition of versions or translations

   2. addition or replacement of formats

   3. addition of taxonomy or metadata values

   4. search engine optimization

   5. accessibility enhancements

Conceivably, a single, multifaceted migration might fulfill a combination of several business objectives, meaning that the complexity of migration dependencies also grows more cumbersome.

Within the business scope of the migration, declare the specific, verifiable outcomes that represent value and that must be delivered to justify the effort of a migration. Possibilities include:

1. Launch – the new, redesigned or evolved site or channel launches

2. Release – the new feature is released

3. Consolidation – multiple Web properties merge into a single property

4. Aggregation – content listings become available or populate with new content

5. Navigation – new landing pages, navigation routes and menu options display

6. Relation – new relationships among content are instituted

7. Separation – designated content is separated into other content types

8. Combination – designated content types are joined with other content types

9. Versioning – new versions of content become available

10. Multilingual – new translated content becomes available

11. Formatting – designated content formats are supported, converted or retired

12. Enrichment – content is enriched with additional taxonomy or other metadata values

13. Search – new content becomes available in search results

14. Search Engine Optimization – content and the site or channel improve in rankings, traffic and transactions as evidenced by analytics data

15. Accessibility – content and the site or channel show provable accessibility improvement

Comprehending the business success criteria of a migration better informs your analysis when untangling the many colliding technical factors in a migration.

Migration of content and the preservation of content dependencies inherently encompasses a wide sphere of technical factors. Technical scope might describe any of the following migration goals that support content administration and facilitate content presentation:

1. Platform Re-use – a site or channel launches on an administration system already in service within the organization

2. Platform Introduction – a site or channel launches on a new administration system

3. Platform Consolidation – disparate administration systems are consolidated into a single platform

4. Platform Reduction – a legacy administration system is retired

5. Content Type Deprecation – designated legacy content types are discontinued

6. Content Optimization – migrated content is enriched with updated markup, encoding, taxonomy or other metadata values

7. Content Configuration – migrated content is reconstituted or refactored, for example:

   1. Formatting – newly supported formats are introduced and designated legacy formats are converted or deprecated

   2. Separation – designated content types are separated into other content types or are internally subdivided

   3. Combination – designated content types are combined into singular structures or objects

   4. Association – new relationships are formed among migrated content, documents or other objects such as events, groups or individuals

   5. Aggregation – migrated content dynamically populates database views and dynamic content listings

8. Search Indexing – migrated content is indexed and available for search facets and queries

9. Content Publication – migrated content is published for availability within front-end features

10. Content Alerts – migrated content is detected and included in or excluded from content alerts

The technical scope of a migration may not always result in visible content differences. New feature sets may present migrated content as it displayed prior to the migration, or in a modified state. When moving an entire site or channel intact onto a new back-end platform – also known as a “lift-and-shift” – there may be no detectable front-end changes or content revisions to the site or channel.

Acceptance criteria must ensure that the production migration meets technical use cases and requirements and that it is testable and reliable. The surface covered by migration specifications is extremely broad. A proven migration outcome might incorporate and test several of these example technical success criteria:

1. Smoke Testing

   1. a new platform is installed and online

   2. disparate legacy administration systems are consolidated and online

   3. a designated legacy administration system is retired and offline

   4. designated content types are deprecated

   5. migrated images and image renditions display

   6. migrated files are served

   7. migrated multilingual content displays in its requisite character set, alignment and flow

2. Integration Testing

   1. a designated subset of migrated content is queryable in search categories or other search facets

   2. a designated subset of migrated content is queryable for dynamic aggregation in a view or listing

   3. a designated subset of migrated content populates landing pages and is linked from menus

   4. content databases are normalized

   5. caches are invalidated and flushed

3. Functionality Testing

   1. the migration can be started, paused, resumed, aborted, re-started, stored and repeated

   2. the migration can be monitored in real time and provides granular progress reporting

   3. logs track migration history, performance, success, failure and reattempts

   4. an individual content item can be tracked end-to-end throughout the migration

4. Data Integrity Testing

   1. a given migration payload contains expected metadata

   2. new relationships are established among designated content

   3. a given type of content is separated into multiple content types or other parts

   4. multiple designated content types are combined into a single given content type

   5. migrated content versions bind to predecessor content in the proper hierarchy

   6. migrated multilingual content binds to source language content in translation sets

   7. migrated content retains formatting

   8. migrated content is converted to new formatting

   9. migrated content is supplemented with additional formats

   10. designated content formats are deprecated

   11. migrated content retains intended encoding

   12. migrated content assumes new encoding

   13. migrated content retains original markup

   14. migrated content retains original element structure and element counts

   15. migrated content adds or is replaced with newer or more compliant markup

   16. migrated content retains or is enriched with metadata values according to a given taxonomy or vocabulary

   17. migrated content retains or is enriched with metadata according to a given schema

   18. migrated content is flagged if the size of a deposited file falls below a defined threshold

   19. migrated content is flagged when a duplicate item is detected

   20. word count of a migrated item matches between origination location and target system

   21. a comparison of a migrated document with the source document results in no redline

   22. x number of items migrate in total

   23. x number of items of a given content type migrate in total

   24. x number of items of a given translation language migrate in total

   25. x number of versioned items migrate in total

   26. x number of new content associations are detected

   27. x number of new content type separations are detected

   28. x number of new content type combinations are detected

   29. content designated as ineligible for migration is withheld from the migration

5. Performance Testing

   1. each designated content item migrates within 1/x seconds

   2. each item in a dropped transaction migrates within x number of reattempts

   3. the overall migration completes within x time

   4. each migrated item is indexed for search purposes within x time

   5. each migrated item is published within x time

   6. page load times drop by x time

   7. search metrics improve

6. End-to-End Testing

   1. file sizes of a migrated item matches between origination location and target system

   2. migrated markup renders in Single Page Applications

   3. migrated files serve from CDNs

   4. expected URLs redirect

   5. expected URLs resolve

   6. expected URLs fail

   7. designated migrated items are marked for inclusion in content alerts

   8. designated migrated items are marked for exclusion from content alerts

7. Accessibility Testing

   1. accessibility scoring improves

8. Security Testing

   1. new content repositories are permissioned for appropriate access

9. Regression Testing

   1. designated content is flagged for quarantine from unexpected and unwanted transformations in the target system

10. Interactive Testing

    1. where expected, newly-authored content mirrors migrated content in its structure and display

When attempting to meet an expansive set of technical success criteria that reflects several high-level goals, a monolithic migration can choke on its own complexity. Consider smaller, phased migrations to reduce technical entanglement and speed the time to product release.

Transformations function as a requisite counterpart to content modeling. They normalize content during – and sometimes after – the migration so that apples and oranges are made to be handled as oranges or pears, so to speak, and so that square pegs are made to fit round holes.

Prior to migration, ascertain how content must be transformed – at some point – to align with new modeling and pending content types. For example, what actions and adjustments will be required to combine, separate, relate, reformat or otherwise refactor content that will be transferred by the migration or to tailor its metadata so that it can be absorbed into new structures?

As to when in a project timeline any content transformations should occur vis-à-vis the migration, there are two options for their sequence: You can perform transformations during the migration itself, while content is en route into the target system; or you can handle transformations post-migration, once content is already inside the target system.

The traditional ETL – Extract, Transform, Load – migration approach is to pre-normalize source content to a viable extent, then to use transformations within the migration system to map, mold and load content for final deposit into its predefined content types in the target system.

Carrying out transformations sooner, versus delaying them, means developing a more sophisticated or a simpler migration system, with corresponding trade-offs on a project timeline: You can move a greater volume of simpler, untransformed content earlier; or you can move a greater volume of complex, transformed content later.

ETL presumes a longer overall elapsed time until the production migration can run at all because this approach front loads the extensive work of finalizing the content model and the complex development of a robust migration system. ETL shifts the actual migration execution step further down the project timeline.

Notwithstanding, content transformations need not always happen during the migration itself. In an ELT – or Extract, Load, Transform – approach, content is reconstituted only post-migration. The migration system brings content into a target system in a more raw form, after which scripting, macro or database operations transform it.

ELT allows for undertaking a migration more quickly, but postpones the heaviest lifting of transforming content into a final form that is fully administrable, usable and presentable by a site, channel or feature. ELT is an advisable – and sometimes unavoidable approach – when support for an administration system is soon being withdrawn or if a legacy administration system is quickly reaching end of life.

Provided that some foundational model exists to receive migrated content – and that the candidate content set is sufficiently normalized to slot into that more primitive model and its content structures – then more intensive transformations and even further, more refined modeling, can be suspended until after content migrates into the target system. 

While they adapt content to the content model and to the requirements of the project, transformations – and the overall migration – also offer opportunities to clean up innate disorder in a content set. Minor but beneficial transformations can enrich content and its metadata with more modern characteristics in these areas:

1. Titles – standardizing TITLE tags and applying other naming conventions

2. Dates – standardizing ISO date formats

3. SEO – arranging header hierarchy, adding metadata descriptions and making other SEO improvements

4. Accessibility – adding ALT attributes, captions and making other accessibility improvements

5. Taxonomy – imprinting core taxonomy values and expanding free tagging

6. Metadata – inserting metadata attributes or other identifiers that are optional in the new content model

7. Formats – converting deprecated content formats to better supported formats

8. Encoding – reencoding content to UTF-8

9. Markup – converting deprecated HTML tags, adding HTML5 tags, adding CSS wrapper elements and repositioning elements within templates

10. Structure – establishing formal relationships among content objects, for example, authors to blogs, minutes to meetings, members to groups, etc.

Content enrichment can be viewed as discretionary. However, given the infrequent nature of migration and the significant resources only temporarily employed, it is convenient to use migration as an occasion to clean up detrimental or defective aspects of content composition, design and assemblage, while polishing it for an optimized front-end experience.

The ensemble of technologies that shepherd content through migration must conform to your business and technical scope, requirements and success criteria. Although longstanding patterns exist across the contemporary Web landscape, the definitive details of the migration engine you devise will be narrowly dictated by your own circumstances and will vary widely by organization, project and specifications.

View a migration system as more than a mere adjunct feature to a larger application. Instead, develop it as a distinct product with its own serious commitment to interface design and usability. Among the must-haves you build in, equip the migration system with the ability to start, pause, resume, abort, re-start, store and repeat a given migration and its configuration. This will permit maximum flexibility for later testing, release planning and code re-use.

As it operates, the migration system needs to access a multitude of other applications and services simultaneously, each with its own – frequently fragmented – information architecture, file system, database schema, access control, network policies, front-end implementation and other technical quirks. At every turn, the migration system must be ready to apply necessary transformations to selected content and ensure metadata enrichment of the final deposited content.

Developing, validating and operating a dedicated, limited-duration mechanism to collect, shape and convey tens of thousands of content items from their origination location safely into a target system is not straightforward. Furthermore, legacy administration systems continue to host source content while content teams access and manage it – even as development of the migration system ensues and you make elaborate plans to divert content elsewhere.

Standard file retrieval, web scraping and data pipeline tools exist upon which a migration system can be built or with which it can be augmented, such as HTTrack, Wget, Scrapy and Talend. Some content management systems such as Terminalfour and Drupal offer platform-specific importers and modules that automate parts of a migration and let you tune the migration configuration as you repeat trial runs.

Ultimately, no migration system can wholly emerge without the indispensable element of human talent. Be ready to enlist key team members to develop the vehicle for the migration, including a database administrator, a regular expression wizard, a Python developer or other scripting specialist, a network engineer, quality assurance testers, content subject matter experts and content managers.

An overlooked duty of the migration system is to embed migration-specific metadata into content to accompany it into the target system. This metadata enables traceability long after migration code and logs have been discarded. It forms the basis for future debugging and building new migration-related business logic. When migrating content, incorporate the pertinent facts of If, When and Where into the metadata of content items that are deposited in the target system. For example:

mgn:migratedContent = true [status indicator for a migrated content item]

mgn:migrationDate = 2023-02-26T23:13:28+0000 [ISO timestamp for when a content item completed migration]

mgn:migrationSource = https://mars.nasa.gov/files/resources/MER10-YearAnniversaryLithograph.pdf [resource locator from which a content item was extracted for migration]

mgn:channelSource = NASA [channel from which a content item was migrated, regardless of its domain or URL]

mgn:channelTarget = SOME NEW CHANNEL [channel into which a content item was migrated, regardless of its domain or URL]

After running a migration, composing queries for subsequent content inventories, audits and migrations will grow increasingly complex as you struggle to disambiguate and exclude previously migrated content. Another useful feature of a migration service is to automatically flag migrated content in the records of the preceding content inventory and content audit to make successive queries more straightforward. For example:

ivy:hasBeenMigrated = true [status indicator for a migrated content item included in an inventory]

ivy:migrationDate = 2023-02-26T23:13:28+0000 [ISO timestamp for when an inventoried content item completed migration]

ivy:inventorySource = https://mars.nasa.gov/files/resources/MER10-YearAnniversaryLithograph.pdf [resource locator used to inventory a content item]

ivy:channelSource = NASA [channel from which a content item was inventoried, regardless of its domain or URL]

ivy:channelTarget = SOME NEW CHANNEL [channel for which a content item was inventoried, regardless of its domain or URL]

adt:hasBeenMigrated = true [status indicator for a migrated content item included in an audit]

adt:migrationDate = 2023-02-26T23:13:28+0000 [ISO timestamp for when an audited content item completed migration]

adt:auditSource = https://mars.nasa.gov/files/resources/MER10-YearAnniversaryLithograph.pdf [resource locator used to audit a content item]

adt:channelSource = NASA [channel from which an inventoried content item was audited, regardless of its domain or URL]

adt:channelTarget = SOME NEW CHANNEL [channel for which an inventoried content item was audited, regardless of its domain or URL]

Migration code is expensive to develop, so upon completion of the production migration decide whether the migration system should be preserved for prospective content sets and projects, still unknown. The circumstances of your project determine whether and how often migration will need to be repeated and the duration for which you must maintain code for the migration system. Evaluate whether a migration will be:

• a one-time, big bang exercise

• a sequence of parceled migrations

• a series of repeated migrations

In situations where new content materializes in standardized sets and at detectable or predictable intervals, the migration system can be kept running in the background as an active, regular process carried out without ongoing developer intervention.

Note that migration code will grow stale as content models decay, systems mature, and developers exit the team. If you sustain the migration capability, ensure that you adequately document its operation by safekeeping original development stories and supplying a companion runbook.

Years of content accumulation across diverse administration systems, conflicting content types, and a chaotic information architecture are sure to foster edge cases in the migration. Not every edge case is arduous to incorporate into the migration system; however, a sizable enough content set tends to raise low-probability but high-difficulty scenarios.

When assessing problematic edge cases, follow this guideline: If one hour of a non-developer resource’s time to manually load a given set of edge case content costs less than one hour of developer time to programmatically migrate that content, then plan on entering data, looking up orphaned items, and associating disjointed items manually in order to handle the edge case.

A novel approach to especially onerous edge case content is to virtualize its migration. In suitable cases, virtualization allows you to circumvent complexity and prevent overinvestment in the migration system. Using this procedure, the migration system carries out its normal actions and transports content metadata and even content relationships into the target system, but bypasses the source content itself, which remains solely at its origination location.

Thereafter, the source content persists at its existing address on your own domain or an external domain – whether it be a Web page, a CDN, a third-party channel or another host. Importantly, the source content remains outside the full scope of the migration – but can be maneuvered through the target system as if it were in fact migrated and were under your control. A trade-off of this technique is that direct editing of the source content via the target system is not always possible.

Business scope, business success criteria and release planning demarcate the candidate content set that is eligible for the production migration. Drawing upon your initial work, the knowledge gathered in the content audit will be the source of truth for precisely identifying audited items to register in a manifest of content to be migrated. A byproduct of preparing the manifest is that you will also determine what content is ineligible for the current migration and that should be deferred.

The audit supplies crucial information to make delineations among the assembled content set as you prepare the migration manifest. You can filter by delimiters in audit metadata such as taxonomy assignments, content types, MIME types and other attributes and categorizations in order to isolate desired content. You should also be able to omit previously migrated content from the manifest based on flags inserted by the migration system in earlier migrations.

Naturally, it is critical that the audit reflects the most accurate and up-to-date organizational content set, and must therefore be based on an inventory that includes the latest authored and published content. The content inventory will need to be refreshed periodically to stay current with production systems and auditors must catch up the audit with the most recent content before you can finalize the manifest.

The format in which you compose the manifest can be a set list of URLs of all content, documents, files and digital assets that are to be migrated, or it can be queries that sequester content items that are to be migrated. By extension, the manifest customarily incorporates a baseline amount of complementary audit metadata. This is information derived from the audit that the migration system requires for processing and transformations, such as dates, storage locations, formats, templates and other nomenclature. 

If you only have a basic auditing system, you may need to manually curate a content list to comprise the manifest. Ideally, with a more advanced auditing system, you can dynamically generate and export the manifest. If you opt to build a generation and export capability, consider that you might output only a single-use manifest, or you might want to reconstruct or re-use the same manifest at recurring or staggered date intervals, in which case a macro or template library would be valuable.

Lastly, in forthcoming migrations it may be useful to return to manifests that you processed in earlier migrations. Determine where and how processed manifests will be stored and versioned within the organization and across content projects. The storage solution should be centrally located and accessible by team members. This might mean using anything from a simple Google sheet, an Airtable spreadsheet or database, a cloud service like GitHub or a purpose-built repository.

The entire range of technical success criteria should be tested ahead of any production migration, whether via automation or by manual inspection to ensure the integrity of migrated content and the reliability of the migration system. Note that transformations performed on content – and even subsequent indexing and publication steps – might affect the applicability or dependability of some of these examinations.

Pre-production migration testing should expose bugs, weaknesses and other issues in the migration system and in the candidate content set. Moreover, while the focus of testing is on validating the migration system, the review of test results also permits you to discover ways to polish the quality of content as it is being migrated, using discretionary transformations.

As test migrations complete, developers, product owners, subject matter experts and content managers can participate in the smoke testing, integration testing, data integrity testing, end-to-end testing, interactive testing and general review of migrated content. To assist this exercise, crawlers like Screaming Frog can help verify front-end details, while administration interfaces in the target system can generate tailored lists of internal migration results.

Consistency in the flow of the migration plan and in the operation of the migration system is vital to testing the many interdependencies enmeshed in the migration. Sequence becomes a key determinant, because the migration of some content items can be a predecessor to the successful migration of other items – the unforeseen presence or absence of a piece of content at the appropriate interval can interrupt or break a part of the wider migration process. 

To tame the complexity of migration testing, consistently refresh data from the production environment to lower UAT and QA environments as test rounds progress. In addition, maintain a manifest that matches as closely as possible the final version you will use for the production migration. The manifest should be regarded as a primary ingredient in the migration code, if not quite code itself. Likewise, changes to legacy content aspects such as formats, encoding or relationships should be applied carefully in order to prevent regressions.

Regardless, due to its far-reaching technical strands, be aware that migration may have unintended impacts in the organizational information ecosystem surrounding the target system. The migration system and the arrival of migrated content in the target system can affect and disrupt downstream applications and services not directly related to the migration or to the project. Thus, it is advisable to arrange and rehearse an exhaustive rollback plan – a reversion to a pre-migration status – should the migration go drastically awry. 

Migrating content repeatedly into new target systems over successive projects introduces it to foreign environments, permissions schemes, file system configurations, administration workflows, system processes, cron jobs, and even rich text editors that can silently alter or mangle it. Stealth issues stemming from migrated content will eventually dispense an abrupt and ugly surprise. Even with versioning and backups in place, restoring content to its initial, intact state after a lengthy period of undetected disruption can pose a formidable challenge.

As you test the migration, watch for undetected variables in the target system that might inadvertently impact the integrity, management and display of migrated content even long after migration finishes. End-to-end testing can reveal some issues early on, when you still have time to insert transformations into the migration system to remediate what would otherwise become expensive headaches. Nonetheless, other issues might surface only much later when a new workflow or integration involving migrated content causes an unanticipated aftereffect.

Some preemptive deterrence measures for vulnerable content include exchanging document formats, converting encoding and addressing non-compliant markup. If it is not feasible to transform content to maintain its integrity in a new environment, it will be necessary instead to arrange guardrails around migrated content in the target system to shield it from corruption. However, quarantining content in this manner is uneconomical to sustain and protective branching of content management should be avoided unless other safeguards cannot avert damage.

At this advanced stage in planning, you can now calculate when in the project timeline and the release plan to schedule the execution of the production migration. The production migration is typically orchestrated to be finished as rapidly as possible in its duration and as near as possible to the launch or release of the site, channel or feature that migrated content will accompany and support.

One of the most essential aspects of planning an upcoming migration is coordinating its timing with impacted stakeholders such as content authors, content managers, end users and other information consumers. Missteps and miscommunications regarding the timing of production migration are costly in terms of interrupted content operations, content inaccessibility, diminished data soundness, protracted rollback steps, and damaged organizational reputation.

A RACI – Responsible, Accounting, Consulted, Informed – chart is helpful in aligning team members and stakeholders as the production migration nears and as you deliberate a go or no-go decision. Clearly identify who has greenlight authority to initiate the production migration or to abort it. Similarly, ensure that key resources are on standby throughout the migration window, along with their specified backups.

It is customary to freeze production content operations – additions, removals and updates – that could conflict with the migration system and its associated processes while a production migration executes. In less technically solidified organizations, the migration system can also worsen strain on content administration systems and slow or cripple routine tasks. Accordingly, plan on keeping content authors and content managers logged out of production environments throughout the production migration.

Standing down production content operations should be done for the minimum time needed to execute the production migration. Taking production content operations offline for an extended period is not realistic, because it creates a growing backlog of work that content managers then need to catch up on once they can log back in. Content teams already have high-profile material they must publish on deadline and SLAs they must meet. Meanwhile, public content grows outdated.

Most production migrations coincide tightly with the product launch or release that will integrate migrated content. Nevertheless, it is possible to finish a migration well before the site, channel or feature that incorporates and presents migrated content actually goes online. This option is usually exercised when launching or releasing with a frozen content set – or when facing uncertainty and requiring flexibility. Consequently, this practice often exposes deficient planning, because it brings unwelcome repercussions and demanding commitments for content teams.

If you defer a product launch or release post-migration, remember that once migration finishes, content teams will still need to maintain – in parallel – both source content in its origination location and migrated content in the target system until the final launch or release. In this scenario, dual content maintenance becomes necessary because the possibility remains that the migration could be rolled back or that the launch or release could be cancelled; and thereafter content teams would need to continue using the legacy administration system for production content operations.

Maintaining content manually and identically in competing systems imposes the need for superfluous coordination and raises the likelihood of errors. Under favorable conditions, such interim content syncing can be done programmatically, though like the migration system itself, automated content synchronization necessitates its own precursors and planning and requires a dedicated development track beforehand. Therefore, completing a migration in close proximity to a product launch or release that the migrated content accompanies and supports remains the default, advisable methodology.

In your delivery strategizing, avoid postponing product launches and releases indefinitely once content has been migrated, because the obligation of concurrent content maintenance burdens content teams over prolonged periods and between the old and new administration systems. If you are contemplating a deferred launch or release after a production migration, it is advisable to revisit the product roadmap and to reformulate the release plan.

Once rigorous analysis, thorough development and exhaustive testing are behind you, executing the production migration should be a formality. The heavy forethought you have devoted up to this point should provide sufficient comfort to trigger the migration at your discretion and in a non-rushed fashion.

As you did in the testing phase, you must still monitor reporting from the activated migration for performance, data loss and discrepancies as it progresses; and though the migration system should offer options to pause and resume, avoid restarting or abandoning the production migration due to the heightened impact this has on stakeholders and production environments.

Now, with the hard work of weeks and months of preparation firmly in place, the migration moment has arrived. Leisurely click the flashing red Migrate button and send your content on its journey forward into the destination system.

Broken links are a mark of shame among migrated content. An artful denouement to a migration is the redirection of content from legacy URLs to new addresses.

If legacy information architecture and URL structures were indiscriminate, you will need to rely on one-to-one matches to manage the bulk of redirections. Where better organized and more consistent URL naming conventions prevail, you can more efficiently redirect content to the target system using pattern matching among directories, pseudodirectories, slugs and parameters.

If you executed only a limited or partial production migration, there is a good chance you left behind substantial image collections or static file repositories in favor of migrating mainly HTML- and text-based content. Where normally requests for now-absent resources would cause 404 errors, alternately load balancer, htaccess and similar redirections can gracefully cascade requests to these leftover files.

A mature organization with an extensive history of content migrations and site or channel relaunches may already control redirections using a dedicated service. When presented with huge volumes of legacy URLs, pinball-style routing rules, and a snarl of redirection chains, weigh the value of developing such a service to more easily define routing logic and response codes, quickly upload URL sets and efficiently flatten inefficient chains.

If a goal of your migration was to retire a legacy administration system, you should retain the system, its data and its files long enough to validate that the candidate content set migrated successfully and is accounted for within the target system. This precaution is advised for legacy production environments, whereas lower legacy QA and UAT instances can be disregarded.

When migration validation is complete and a legacy administration system can be retired responsibly, preserve both its database and a static dump of the its file collection in cold storage, subject to retention policies. Stored legacy data and files offer the most utility in the short-term, because over time it becomes increasingly difficult to reconstitute a long-dead administration system.

With migration confirmed and the relevant site, channel or features delivered, your migrated content should now be on the Web and the source content that informed the migration should be offline and inaccessible in its original form. You may want to retain instances of source content for safekeeping should long-term questions arise about the intactness or structure of migrated content, whereupon these snapshots will prove invaluable for consultation. 

Retention of source content may also be necessary for other research and reference purposes, for versioning and comparison, or if it becomes compulsory to produce original content for archival, legal, compliance, governance or technical reasons. Finally, with any of those concerns resolved and with standard backups and versioning covering migrated content in the target system, any source content remaining at its origination location becomes subject to deletion. 

The strenuous exercise of content migration contributes best practices to an organization’s subsequent migration planning in all its dimensions, including refocused business and technical deliberations, refined categorization of content collections, retirement of legacy administration systems, introduction of modern transformation capabilities, and improved product management and software development.

Looking back, your successful migration brought enlivened information to users and equipped your team with enhanced knowledge as you proceed to your next migration.

Content and the systems in which it lives remain fickle and fleeting. Restless content and rising platforms lie just beyond the approaching Web horizon. Content migration will soon again be in your future – and now you have a plan.