Pack your group’s data before it has to move.

1. Decide what the package must let you do.

Write the intended outcome before selecting an export button. A readable copy for a departing member, a move to another application and a full recovery of the existing service need different material. One export may serve the first purpose well and fail the other two.

BookStack makes this distinction explicit: its content export and import tools are not intended as backup and restore. A readable HTML or PDF copy is useful, but it should not silently replace the recovery set for the application. BookStack exporting and importing content.

For a hypothetical workshop group, the initial goal is modest: another authorized maintainer can read the operating handbook and import a representative section, including its diagrams, into a separate test instance.

2. Record the format and the gaps.

Create a matrix that describes what you need to preserve and how you will prove it. Do not put “complete” in a cell until you have checked the destination.

BookStack documents a portable ZIP format containing content data, attachments and images that can be re-imported to BookStack. That does not establish compatibility with another wiki or preservation of every service-level setting. BookStack export formats.

3. Give the package a human starting point.

Add a short readme with the source application and version, export date and timezone, selected scope, exporter’s role, file list and expected destination. Use descriptive folder names such as readable-content, attachments and import-package. Keep credentials elsewhere; write only the approved retrieval procedure for authorized maintainers.

The hypothetical handbook contains an opening checklist, a machine-care page, a diagram and one linked spreadsheet. Its manifest records those four items, their relative paths and the relationship between the page and its attachment. Also record a restricted page as deliberately excluded, so an absence is not later mistaken for accidental loss.

A checksum can help identify an unchanged file during transfer. It does not prove that the export was complete, correctly permissioned or readable.

4. Inspect a representative sample.

Open the readable copy without relying on an active session in the original application. Follow a link, inspect an embedded image and open the linked attachment. Look for references that still lead back to the source service. Record which links are intentionally external and which would break after a move.

For calendars, choose a sample that includes a repeating event, an exception and an event with a relevant timezone. Nextcloud documents calendar export and iCalendar-compatible .ics import. That establishes a supported exchange path, not proof that your target preserves every chosen feature. Nextcloud Calendar import and export.

Check the documentation for your installed release before following interface labels; the linked rolling manual may describe a different version.

5. Import into a separate, controlled destination.

Use an empty test destination or an explicitly approved test collection. Keep the working service and its original data untouched. Disable outgoing notifications and contain external connections before starting the imported application; the purpose is to assess the data, not resend historical events to members.

Have the second maintainer follow the readme without relying on undocumented instructions from the exporter. Compare the expected items with the imported result. Verify the diagram, spreadsheet link, page structure and the intended member permissions. Record any role mapping that requires manual work. If a format lacks a needed feature, decide whether to reconstruct it, choose another export method or keep a readable archive alongside the new service.

6. Make failure informative.

If files are missing, compare export scope and exporter permissions before repeatedly producing larger archives. If links break, determine whether they reference the old service or a file absent from the package. If the import creates unexpected duplicates, stop and inspect its matching rules before importing the same package again.

For the workshop example, acceptance means the second maintainer can read and edit the selected pages, retrieve each included file and demonstrate that a normal member cannot access the excluded material. Record each result and its reviewer. “The import finished” is only one observation. Keep unresolved differences listed alongside the package so the group can make a deliberate decision about them.

7. Keep exports and recovery in their own lanes.

Store an accepted package in a controlled location independent of the source service and agree when to refresh it. Review again after changes to important formats, permissions or application versions. Export files can contain private content even when the destination is only temporary, so assign access and a retention decision to them too.

Keep the application recovery set separately: BookStack’s recovery documentation, for example, requires database and file material beyond a readable document export. BookStack backup and restore requirements.

Continue with the restore drill for service recovery, the storage worksheet for export working space and the service inventory for dependencies. Portability is something to demonstrate with your package, not assume from a file extension.