DITA is an open standard, so teams reasonably expect their content to be portable. The XML may indeed be exportable. The harder question is whether another environment can understand, validate, resolve, and publish it with the same behavior.
Files are only part of the system
A useful DITA corpus depends on maps, keys, conrefs, subject schemes, DITAVAL files, catalogs, specialization shells, Schematron rules, plugins, and publishing parameters. Exporting topics without these dependencies preserves text while losing the operating model that gives the content meaning.
Proprietary representations add another boundary
Some platforms translate content into an internal canonical model and reconstruct XML during export. Even when the output looks like DITA, identifiers, metadata, ordering, namespaces, or processing expectations may have changed. Round-trip testing should examine both semantic fidelity and proprietary additions.
Portability needs an exit contract
A serious platform should define what an export contains, how resource identity is represented, how binaries are included, which toolchain assets belong to the tenant, and what manifest describes the package. The organization should be able to inspect that contract before migration pressure exists.
Native XML is the foundation, not the finish line
ForgeDITA keeps DITA XML as the system of record and treats tenant-owned processing assets as part of the portability boundary. That does not make every migration trivial. It makes the dependencies visible and gives the organization material it can move without first reverse-engineering the platform.
The ForgeDITA position
ForgeDITA is being built around explicit contracts, native content, contextual DITA semantics, and evidence that can be inspected. The current beta boundary and limitations are published on the product status page, with technical material available in the public repository.