FileNet to Nuxeo: planning the migration beyond document counts

Separate the migration into decisions you can test

A document count describes scale, but it does not fully describe migration difficulty. Versions, folder relationships, access rules, binary sizes, and the way teams adopt the target system can change both the implementation and the cutover plan.

Start by defining what must remain true when the content reaches Nuxeo. That definition should be specific enough for the business to validate before the old system is retired.

Lessons from the original migration account

In my September 2022 article, I described FileNet migrations in which the target requirements differed substantially. One project needed business-rule validation, existing folder structures, versions, and proxies; another used a flat structure. The account also described preparing data before import, moving binaries separately, and changing over business teams in stages.

Those examples support an important planning principle: choose the migration design around the content model and acceptance criteria. A throughput figure from one project is not a delivery commitment for another. Original migration account

Define the content contract

For each source record type, agree on the destination document type and metadata mapping. Document how the migration should treat missing fields, invalid values, duplicates, folder relationships, versions, and permissions.

Use a representative sample to challenge the mapping. Include records the business finds difficult, not only the examples that import cleanly. Decide which records may be transformed automatically and which require an explicit exception decision.

Track binaries and metadata independently

A binary-transfer plan and a metadata-import plan should have their own progress and reconciliation checks. Preserve the relationship between each source document and the correct target binary throughout the process.

For acceptance, confirm both that the expected record exists and that the correct file can be retrieved by an authorized user. Counts alone cannot establish that result. A matching hash may help check integrity; it does not replace encryption or authorization.

Plan cutover around a business workflow

Choose a pilot whose owners can define success. Agree when its source data is extracted, how changes after extraction will be reconciled, when new work moves to Nuxeo, and what conditions would trigger a rollback or pause.

Measure the complete sequence: preparation, transfer, import, indexing, exception handling, and business validation. This gives the team a more useful planning basis than an isolated import benchmark.

Keep the original scope visible when requirements change

A migration can become a broader platform program when teams add publishing, workflow, or DAM requirements. Track those additions as explicit scope decisions with their own acceptance criteria. Do not let them silently change the meaning of "migration complete."

Maretha's follow-up migration article describes the subsequent toolset and processing pattern. For a migration review, see Maretha migration services.