Converting Ami Pro .SAM to OpenDocument (ODT)

Why ODT for long-term records

OpenDocument Format is standardised as ISO/IEC 26300 and developed in the open. That matters for records with 20-, 50-, or permanent retention periods, because the format specification does not depend on a single company continuing to support it — or continuing to exist. Ami Pro is the object lesson in what happens when it does.

This is why ODF appears in so many public-sector procurement and retention policies across Europe and beyond, and why universities and research institutions with long-horizon archives often prefer it. If your policy names ODF, converting Ami Pro documents to .odt is a direct route to compliance rather than a conversation about equivalence.

There is also a practical benefit for mixed environments. ODT is read natively by LibreOffice, OpenOffice, Collabora, and modern Microsoft Word, so the same file works whether a given desk runs open-source or commercial software.

The awkward gap: LibreOffice cannot read Ami Pro

LibreOffice is normally the hero of legacy format stories. It ships import filters for WordPerfect, ClarisWorks, MacWrite, early Word, Lotus spreadsheet formats, and a long list of other obsolete applications, all maintained by people who care deeply about not losing documents.

Ami Pro is a genuine hole in that coverage. There has never been a .SAM import filter, so the application that writes ODT natively cannot open the documents you want to convert. The advice that solves the WordPerfect problem — install LibreOffice, open the file, save as ODT — simply fails here.

The workaround people attempt is a two-step: convert .SAM to DOCX with something, then open the DOCX in LibreOffice and save as ODT. It works, but it stacks two conversions and two sets of compromises. Going directly from .SAM to ODT is one translation instead of two, and one place to look when something is wrong.

What carries across into ODT

• Paragraph and character styles derived from the .STY style sheet, mapped onto ODF styles
• Tables as native ODF table structures with borders and cell content intact
• Lists as ODF list structures rather than literal bullet characters
• Inline formatting — bold, italic, underline, superscript, subscript, font changes
• Recovered WMF/EMF diagrams and rendered equations embedded as images
• Text normalised to UTF-8, so legacy code page characters survive correctly

ODF’s style model is a good fit for Ami Pro

There is a pleasing symmetry here. Ami Pro separated content from presentation with .STY style sheets years before that was mainstream, and ODF is built on a similarly explicit style model with named paragraph and text styles carried in the document package.

The result is that Ami Pro style names tend to map onto ODF styles cleanly, and the converted document keeps a real hierarchy rather than a series of directly formatted paragraphs. You can open the Styles pane in LibreOffice Writer, adjust a heading style once, and see the whole document follow — the same behaviour the original author relied on.

This is the strongest practical argument for converting directly to ODT rather than laundering the document through DOCX. Each additional hop flattens structure a little, and structure is precisely what makes a long document maintainable.

A public-sector conversion checklist

Retention, reconciliation, and originals

Treat the conversion as a records event rather than a file operation. Count the source documents before you start, count the outputs afterwards, and reconcile the difference against the conversion log so every gap has a documented explanation.

Retain the original .sam files and their .STY style sheets indefinitely. A retention policy that permits destroying source documents after migration is implicitly asserting the migration was lossless — an assertion nobody can make about a cross-format conversion. Keeping a few gigabytes of originals is cheap insurance.

Store the log alongside the output. Years later, the question will not be whether ODT was the right format; it will be whether a specific document was migrated, and the log is the only thing that answers it quickly.