Migration

HomeMigration → From an existing CSDB

Migrating from an existing CSDB

An existing S1000D Common Source Database — Adept, Astoria, or a program-built CSDB — holds DMs, graphics, BREX, CIR, and applicability tables in vendor-specific shapes. Ironmark's ingest path pulls the standard artifacts in directly and gives you a review pass for the vendor-specific parts before they land in the project.

What travels

Data Modules (DMs)Direct. S1000D-conformant XML travels straight into the project. Version detected from the DM (4.2 / 5.0 / 6.0) and matched to the project SDM.
Graphics (ICNs)Direct. Filenames preserved; cross-project uniqueness enforced so a shared ICN across two source manuals doesn't collide.
BREX rulesDirect. BREX DMs load into the project's BREX registry. Structural + non-structural rules parsed to widgets where possible; the underlying XPath stays for round-trip.
CIR entriesDirect. Warnings, cautions, tools, supplies, parts, personnel, prerequisites — each with its S1000D-native repository type on the Ironmark side.
Applicability (ACT/PCT)Direct. Applicability cross-reference tables and product cross-reference tables ingest into the project's applicability model.
TOC / PMDirect. Publication Modules parsed to the Publication Builder's TOC surface.
DDNDirect. Data Dispatch Notes ingest into the first-class DDN surface.
Vendor-specific metadataReview pass. Adept baseline metadata, Astoria workflow state, and program-specific attribute extensions surface in the ingest report. Map to Ironmark's equivalent or keep as passthrough.
CMS workflow stateCase-by-case. Review status and check-in / check-out state from the source CMS doesn't come across as workflow state; that data lands as ingest-time metadata for reference. New reviews start fresh in Ironmark.

Ingest path

1. Export from the source CSDB

Two common shapes:

2. Create a project on the target SDM

Match the source's S1000D version. If the source is 4.2 and you're moving to 5.0 as part of the migration, ingest into a 4.2 project first, then run the version-upgrade path once the ingest is clean.

3. Ingest and review the report

Report lists per-DM disposition, unresolved xrefs, orphaned graphics, and vendor-specific constructs. Fix or accept-as-passthrough per row.

4. Reconcile stale dmRefs

Existing CSDBs often have accumulated stale dmRef targets from ad-hoc DMC renames. Ironmark's reconcile-stale-dmRefs report scans the ingested project and flags orphans; the fix action either points them at the correct target or removes them.

5. Baseline the pre-edit state

Cut a baseline before editing starts. This is your rollback anchor and your "as-imported" reference for auditors.

Provenance preservation

The ingest record keeps the source archive checksum and the ingest disposition report attached to the project. A future auditor asking "which CSDB export did this project originate from" gets an answer without needing to reconstruct it from commit history. Combined with baselines, the chain from source CSDB → ingested project → shipped manual is traceable end-to-end.

An existing CSDB migration is usually not a lift-and-shift — programs use the migration as a chance to consolidate BREX, retire dead DMs, and align applicability. Ironmark's ingest is designed to let that consolidation happen inside a review pass rather than being forced up front, so you're editing content in Ironmark rather than staging it in the source CSDB before you leave.

Related

← All migration guides