FAQ & Common Pitfalls
Answers to frequently asked questions and warnings about common migration mistakes.
Frequently Asked Questions
Do I need to migrate everything at once?
No. You can migrate incrementally:
- Start with terminology and status model updates
- Add governance features later if needed
- Concept plane can be added as a second phase
However, declare your target register type upfront so you know what you're working toward.
Can I keep using my existing XML schema?
Yes. The 2026 edition is technology-neutral, which means:
- Your existing XML schema is still valid, just not normative
- You can continue using any encoding technology
- No requirement to change your underlying technology
The standard no longer prescribes a specific implementation technology.
What happens to items with "submitted" status?
The "submitted" status has no equivalent in 2026 because proposals are now separate from register items. Options:
- Best: Complete the review process before migration
- Alternative: Convert to proposals in the new system
- Simplest: Archive and handle separately
Is retired the same as invalid?
No! This is a common misconception:
- Retired = Still valid, just not recommended for new use (publication=unpublished)
- Invalid = Contains errors, not suitable for any use (validity=invalid)
A retired item might still be needed for historical data; an invalid item should not be used at all.
Do I need to implement the concept plane?
It depends on your target register type:
- Content Register: No, concepts are implicit
- Governed Content Register: No, this is the 2015 Extended equivalent
- Concept Register or higher: Yes, explicit concept management required
Most 2015 registers can migrate to Governed Content Register without implementing the concept plane.
What are commitments and do I need them?
Commitments are explicit promises about access, persistence, and transparency:
- Minimum required: Identifier persistence (identifiers never change)
- Higher levels provide stronger guarantees but require more infrastructure
- Declare only what you can reliably deliver
Governed registers must declare commitments; Content Registers do not.
Can I still remove items from my register?
The 2026 edition requires persistence. Instead of removal:
- Use unpublished status to hide items
- Use redaction to hide specific content
- Use deletion flag (metadata remains, content removed from views)
For highest commitment (append-only), even deleted content metadata must be retained.
How do I handle the predecessor/successor relationship changes?
The relationship model has expanded:
- predecessor becomes a
supersedesrelation (current item supersedes predecessor) - successor becomes a
superseded byrelation - New relations available:
inherits,has part, etc.
The direction of the relationship matters—be consistent in your implementation.
What if my register doesn't fit any of the migration paths?
Contact the FERIN community or ISO/TC 211 for guidance. Special cases include:
- Federated register topologies
- Custom governance models
- Legacy data with unusual patterns
The standard is designed to be extensible—custom solutions are possible.
How long should I plan for migration?
Typical timelines by register type:
- Content Register: 1-2 weeks
- Governed Content Register: 2-4 weeks
- Governed Concept Register: 4-8 weeks
- CCR: 10-16 weeks
Add buffer time for testing and stakeholder review.
Common Pitfalls
Mapping retired → invalid
Wrong Approach
Setting validity=invalid for retired items because they're "not for use"
Correct Approach
Retired items are still valid—they're just unpublished. Use validity=valid, publication=unpublished
Ignoring the "submitted" status issue
Wrong Approach
Trying to migrate submitted items as-is without handling the conceptual change
Correct Approach
Process or archive all submitted items before migration; proposals are separate from register items in 2026
Over-declaring commitments
Wrong Approach
Declaring highest commitment levels because they sound good
Correct Approach
Declare only what you can reliably deliver; under-delivering on commitments violates conformance
Forgetting supersession is now a relation
Wrong Approach
Trying to encode supersession in the status value itself
Correct Approach
Supersession is a separate relation between items, not part of status dimensions
Removing XML schema entirely
Wrong Approach
Deleting all XML infrastructure because "the standard is technology-neutral"
Correct Approach
Keep what works; technology-neutral means any technology is acceptable, including XML
Migrating without a rollback plan
Wrong Approach
Running migration directly on production data
Correct Approach
Always test on a copy first, maintain rollback capability, and have a verification plan
Not updating external documentation
Wrong Approach
Migrating the system but leaving user documentation with old terminology
Correct Approach
Update all documentation, APIs, training materials, and user guides with new terminology
Underestimating concept plane effort
Wrong Approach
Planning a quick migration to Governed Concept Register without understanding concept extraction
Correct Approach
Extracting concepts from existing content is often the longest task—plan accordingly
Quick Reference
Status Mapping Quick Reference
valid | → validity=valid, publication=published |
invalid | → validity=invalid |
retired | → validity=valid, publication=unpublished |
superseded | → validity=valid + supersession relation |
submitted | → No direct mapping (proposals separate) |
Role Name Changes
| Submitting Organization | → Proposer |
| Registry Manager | → System Manager |
| Technical Standard | → Register Specification |
| Register Item Series | → Concept |
Conformance Mapping
| Core | → Content Register |
| Extended | → Governed Content Register |
| Hierarchical | → Governed Concept Register |