Whether you're evaluating a replacement, building a report your system won't produce, or just want a copy of your own records, the first practical step is the same: get the data out. This guide covers what to export from Axxerion, which fields actually matter downstream, and the data-quality problems that quietly ruin reporting if you don't catch them early.
It's written to be useful whether or not you ever talk to us.
One naming note before we start: Axxerion was acquired by Spacewell, and the product line now sits under the Spacewell brand — Spacewell Workplace and Spacewell Real Estate. Plenty of teams still say “Axxerion,” so we use both names here. Everything below applies either way.
Start with the four datasets that matter
Most facilities systems hold far more than you need to move. In practice, four exports carry almost all the operational value:
- Work orders — the transactional history. This is the big one, and the one your reporting depends on.
- Leases and lease abstracts — terms, dates, financials, and clauses. Painful to rebuild by hand, and the source of expensive mistakes if a renewal date goes missing.
- Properties, buildings, and suites — the spine everything else attaches to.
- Vendors and organizations — including insurance certificates and expiry dates if you track them.
Export each separately rather than trying to produce one merged file. Merged exports lose the relationships between records and are much harder to validate.
Work orders: the fields worth insisting on
Export to Excel or CSV, and resist the temptation to trim columns to make the file tidy. The fields below are the ones people most often wish they'd kept:
| Field | Why it matters later |
|---|---|
| Work order number | Your only stable link back to the old system. Never regenerate these on import — you'll break every historical reference, invoice match, and email thread. |
| Requested / created date | The basis of every volume trend. Without it you cannot compare months. |
| Completed / closed date | Combined with the requested date, this gives completion time — usually the single most-requested metric. |
| First assignment / accepted date | Enables response time, which is a better measure of team performance than completion time (which depends heavily on the vendor and the job). |
| Status | Export the raw status values, not a simplified open/closed flag. You can always simplify later; you can't recover detail you discarded. |
| Property / branch identifier | Prefer a stable code over a display name. Names get renamed; codes usually don't. |
| Problem / issue category | Drives every “what's breaking most” analysis. See the warning about free text below. |
| Vendor | Needed for vendor performance and spend analysis. Frequently incomplete — check it early. |
| Priority | Lets you separate emergencies from routine work when measuring response times. |
| Description and notes | Bulky, but it's the context that makes a historical record worth keeping. |
Large exports time out, truncate silently, or produce files Excel struggles to open. Pull a year at a time — or a quarter for a big portfolio. Smaller batches are also far easier to validate, and if one fails you re-pull one batch instead of everything.
Five data-quality traps to check before you trust anything
1. Free-text problem categories
If your problem or issue field allows free text, you almost certainly have “HVAC,” “H-VAC,” “hvac,” and “Heating/Cooling” all describing the same thing. Run a pivot on that column and count distinct values. If a portfolio of a few hundred properties produces 200+ distinct categories, you have a normalization job ahead of you — better to discover that now than after you've built a dashboard on it.
2. Missing vendor on completed work
Very common, and it skews vendor performance reporting in a way that's hard to notice. Filter for completed work orders with an empty vendor field. If it's a small percentage, decide whether to backfill or exclude them — and write the decision down so the number is explainable later.
3. Dates that are text, not dates
Exports frequently produce dates as strings, sometimes in mixed formats within the same column. Sort the column and look at both ends: if 1/2/2026 and 2026-01-02 both appear, you have a parsing problem. Ambiguous day/month ordering is the worst version of this, because it fails silently and produces plausible-looking wrong answers.
4. Status values that don't map to a clean lifecycle
Over years of use, most systems accumulate statuses that overlap or were used inconsistently by different teams. List the distinct values with a count for each. You'll usually find a handful that account for 95% of records and a long tail that needs a decision.
5. Duplicate work order numbers
Rare, but worth ruling out. Duplicates usually mean the export overlapped two batches, or a record was reopened and re-exported. Check for uniqueness before you import anything anywhere.
Leases: export the abstract, not just the record
Lease data is where the most valuable — and least reproducible — information lives. When you export, make sure you capture:
- Parties, property, and the specific suite or unit the lease covers
- Commencement and expiration dates, plus the rent schedule by period, not just a single current rent figure
- Renewal options — how many, and the term of each
- The notice period, which determines the date by which you must act on a renewal
- Clauses and any attached documents
That fourth item is the one that costs real money when it goes missing. If your notice date lives only in someone's calendar, a lease can auto-renew — or lapse — because nobody was watching. Any system you move to should calculate that date from the lease end date rather than relying on a person to maintain it.
Keeping months comparable
The most common reporting mistake after a data migration isn't losing records — it's producing trends that aren't comparable month to month. Three rules prevent most of it:
- Pick one date as your reporting anchor and use it consistently. Requested date is usually right: it reflects when demand arrived, and it doesn't move when a job finally closes months later.
- Decide how to treat open items at the period boundary. A work order opened in March and completed in May will distort either month depending on how you count it. Be explicit and stay consistent.
- Normalize categories before you build the report, not after. Re-mapping categories later invalidates every trend you've already shown people.
A short pre-flight checklist
- Row counts match what the source system reports for the same date range
- Work order numbers are unique
- Dates parse consistently, with no ambiguous formats
- Distinct status and category values are listed, counted, and mapped
- Missing-vendor and missing-date rates are measured and a decision recorded
- Lease notice dates are captured, not just start and end dates
- Files are stored somewhere durable and access-controlled — this is operational data about real properties and people
We built our import around exactly these files. Bedrok Pro reads Axxerion Excel exports directly — work-order history preserving numbers, dates, vendors, and status; lease abstracts and clauses; properties and vendors matched on import — validating every row against the property category's schema and flagging problems at the row level before anything is saved.
The point is that you go live with your real history instead of an empty system. Send us an export and we'll load it so you can see your own portfolio, or read more about moving off Axxerion.
One last piece of advice that has nothing to do with software: export your data beforeyou need it. Teams often discover data-quality problems during a migration, under time pressure, when there's the least room to deal with them. A clean export you did calmly last quarter is worth far more than a rushed one during a cutover.