A content-management migration can look perfect from the front page and still destroy part of the historical record.
The reason is simple: the version you see today is not always the only version that ever mattered. A long-running page may have years of revisions behind it — corrections, changed claims, deleted paragraphs, updated links, different authors, and revision notes explaining why something changed. When a site moves from one CMS to another, those earlier states are easy to leave behind because the migration team is usually focused on getting the current page online.
Drupal makes the problem unusually visible because revisions are explicit records rather than invisible editor state. Drupal’s revision documentation shows that revisions can carry timestamps, authors, log messages, and complete earlier content states. Its migration system separately documents migration of node revisions, including the need to map revision identifiers. Moving the current article and moving its history are therefore separate jobs.
That distinction matters outside Drupal too. A replacement CMS may import title, body, author, and publication date while ignoring the old system’s revision tables. The visible site survives. The evidence of how it became that site does not.
What revision history can tell us
Revision history is useful when researchers need to answer questions the current page cannot answer. When was a statement added? Was a number corrected after publication? Did a product page once promise a feature that later disappeared? Did an agency quietly rewrite guidance rather than publish a new document?
Without revisions, the surviving page becomes a flattened final state. It is still useful, but it has lost chronology.
That history matters because reverting a Drupal page does not erase the later revisions; the system creates another revision while retaining the older record. A migration that flattens everything to one current page throws away chronology the source CMS intentionally preserved.
A proper export needs more than HTML
Preserving revision history requires exporting the relationships between the versions as well as the text itself. Useful migration data can include revision IDs, timestamps, authorship, status, moderation state, log messages, attachments, and which revision was current at a given time.
If the old system is still running, this is mostly an engineering problem. Once the database has been retired, overwritten, or discarded, recovery becomes much harder. A Wayback Machine capture may preserve several public versions of a page, but it will not recreate every internal revision the CMS once knew about.
That is the quiet danger of CMS replacement. Nothing has to look broken. The new site can be faster, cleaner, and technically successful while an invisible layer of its history disappears during launch weekend.