AdemeroHelp

Troubleshooting a Content Central migration

Find your symptom, see what it actually means, and fix it — stored paths, folder permissions, search indexes, licensing, and the other usual suspects after a server move.

AdministratorsContent Central 7.xVaries by symptomVerified 2026-08-30

Find your symptom below and follow its fix. Almost every post-migration problem is one of five things: an incomplete file copy, folder permissions that didn't survive the copy, stored paths still pointing at the old layout, a search index that needs rebuilding, or the license needing re-activation. All five are fixable without redoing the migration.

Note

The fastest diagnostic is the Migration Assistant's Stage 7 — Verify. It's read-only and safe to run any time: it spot-checks real documents on disk, checks write permission on every storage folder, and cross-checks each search index against the database — then names exactly what's wrong. When in doubt, run Verify first and let it point you at the right section below.

"Document not found" or documents won't open

The database knows the document, but the file isn't where the database says it is. Three causes, in order of likelihood:

  1. The file copy was incomplete. Re-run your original robocopy command — it's safe to repeat and only fills in what's missing. Check the log summary: FAILED must be 0, and compare total file counts between old and new servers.

  1. Documents live at a different path than the database expects. This happens when a storage folder moved to a new location but the paths stored in the database were never rewritten — for example, documents that lived at E:\CCDocuments copied to D:\CCDocuments. Fix: run the Migration Assistant's Stage 3 (Map) and Stage 4 (Rewrite) — Stage 4 previews exactly how many records each mapping updates before writing anything, takes its own backup first, and applies all-or-nothing.

    warning

    Do not fix paths by hand-editing the database. Document paths are stored in more than a dozen tables, several of them denormalized copies — a partial hand-fix leaves the system internally inconsistent in ways that surface weeks later. The Rewrite stage exists precisely because "just update the one table" is never actually one table.

  1. A storage root was never copied at all. Organizations sometimes relocate one folder (like thumbnails or the coding queue) years ago and forget. The Assistant's Stage 2 (Discover) lists every folder location the database knows and whether it exists on this server — anything marked "not found" that isn't deliberate needs copying.

"Access denied" or "file is locked" errors

Windows permissions do not follow a file copy. The Content Central website and services need Modify rights on every storage folder.

  1. On each top-level storage folder: Properties > Security > Edit, grant Modify to NETWORK SERVICE and Administrators, and apply to all subfolders and files.

  2. Run the Assistant's Stage 7 — Verify: its permission check names the exact folder and account combination that's blocked.

Search returns nothing, or finds documents that won't open

Search indexes have two failure modes after a migration, and they look similar from the outside:

  • The index is still rebuilding. After a path change, every catalog's index rebuilds from scratch. Until it finishes, search results are incomplete — but every document remains fully accessible by browsing. Rebuilds only progress while the Content Central services are running; a rebuild that "never finishes" is almost always stopped services.
  • The index is stale — it remembers the old server's paths. Each search index stores the full path of every indexed document. If document paths changed but the indexes weren't rebuilt, search returns hits that point at files that no longer exist there. Fix: re-run the Assistant's Stage 5 (Indexes), or rebuild the affected catalog's index from catalog administration in Content Central, then let the services finish.
Note

New documents added right after a migration also take a short while to appear in search — indexing runs on a schedule, not instantly. Give it a few minutes before diagnosing.

Users can't log in, or single sign-on stopped working

If your organization uses SSO, the new server needs the same web encryption keys as the old one (the machineKey — a server-specific setting your IT team carried over, or didn't). The Assistant's Stage 6 (Fixups) detects a missing machineKey and shows the exact instruction; forward it to whoever manages your IIS. Regular username/password login is unaffected by this.

License shows "Invalid" or unactivated

Expected after every migration — the license is tied to the old server's hardware fingerprint and never transfers. Re-activate on the new server with your license key (Stage 6 shows the exact command). Two specific cases:

  • Activation says the seat is in use — the old server still holds it. Contact Ademero support to release it.
  • Activation can't reach the licensing service — the new server's firewall is blocking outbound HTTPS. Activation cannot complete without it; contact Ademero support for the current firewall allow-list requirements.

Email notification links point at the old server

The server address is stored in the database and embedded in notification emails — it does not update itself when the hostname changes, it just keeps working with the stale value silently. Run the Assistant's Stage 6 (Fixups) and enter the new address when prompted.

Scanning workstations can't connect

If the server URL changed, each workstation running the DirectScan Agent or Content Director still trusts the old URL and needs its setting updated to the new one. This is per-workstation — the server can't fix it centrally.

Things behaving strangely in ways not listed here

Check the basics in order:

  1. Are all five Content Central services running on the new server, plus the website in IIS?

  2. Is the old server truly stopped? If both servers' services run against copied data, they diverge irrecoverably — stop the old server's Content Central services now and set them to Disabled. This "split-brain" state is the one genuinely dangerous post-migration condition.

  3. Read the startup warnings. When the website starts, Content Central validates its configured folders and reports clearly if one is unreachable — treat any startup warning as a real finding, not noise.

  4. Check the logs in C:\ProgramData\Ademero\Content Central\Logs\ and the Windows event log for errors from the five services.

Still stuck?

Contact Ademero support with two attachments and one sentence:

  • The Migration Assistant's newest log file (the exact path is shown in the Assistant's header) — it records every action and decision, so support sees precisely what happened without a screen share.
  • The Stage 7 Verify output (the Copy button captures it).
  • One sentence: what you migrated, whether paths changed, and what symptom you're seeing.