Migrating to Heyllave is not uploading a file: there is no bulk import and no CSV load. Records come in by hand from the screens, or programmatically against the API. That sounds like bad news and it actually settles the strategy: because loading data costs effort, you want to load it once — and for that you need to get a few decisions right before the first record.
Because some of those decisions cannot be changed afterwards.
What locks
This is the section worth reading twice. Everything else about a migration can be corrected; this cannot.
| Decision | When it locks | What happens if you get it wrong |
|---|---|---|
| An entity type’s internal identifier | When the type is created | You have to create another type and load its records again. |
| A type’s public identifier strategy | As soon as the type has one record | The ids already issued are in documents, references and conversations. They are not renumbered. |
| That identifier’s prefix and digits | Same as the strategy | cus-1 would live alongside CUS-0001 forever. |
| A bookable service’s key | When you edit it | The key identifies the service; it is then fixed. |
| A public page’s slug | When the page is created | The public address has already been shared or indexed. |
Two more do not technically lock but behave as though they did:
- An item’s unit. Changing it once there are movements forces you to reinterpret the whole inventory history. Litre, metre, box or each: decide before loading quantities.
- The numbering strategy for orders and items. Changing it later does not renumber what already exists: it only changes what comes next. You end up with two formats in one history.
The order that avoids redoing the work
Each step depends on the one before it. Skipping one is what forces you back.
- Workspace identity and preferencesName, logo, language and time zone. The time zone is the reference for limits and period boundaries, so do not leave it for later.Before any data
- Enable only the modules your chosen flow needsIf you are not invoicing yet, do not enable Invoicing. A disabled module is harmless; a half-configured enabled one is not.Check the dependencies
- Design the entity types and their relationshipsCustomers, vehicles, equipment, properties. Define the fields, the field that titles each record, which fields are searchable, and the identifier strategy.This is where the locks are
- Create roles from real jobsBefore inviting anyone. It is far easier to widen a permission when somebody asks than to take one away after half the team got used to it.
- Inventory locations and catalogLocations first, then items, quantities last. Decide which categories track stock and each item’s unit.Quantities last
- Services, resources and availabilityIf you schedule appointments. A service’s key is then fixed, so name it with two years in mind.
- Document types and notification rulesTemplates, signatures, and which event triggers which message. Test every rule with a colleague before pointing it at customers.
- Load the dataCustomers first, then their assets, then the relationships between them. Open balances last.
- Invite the teamOnce there is something to look at. An empty workspace demonstrates the product badly.
- Walk one complete case through with test dataFrom request to payment. Then delete or archive that case.Do not skip this step
How the data gets in
Choosing the loading route
How many records are you bringing?For the programmatic route, see Connect another tool. Load a small batch first, check how one complete record looks on the screen, and only then load the rest.
What does not migrate, and what to do instead
- Documents already issued in another system. Do not recreate them as issued documents here: you would duplicate numbering and leave a false accounting trail. Keep them where they are, as an archive, and start Heyllave’s numbering where it belongs.
- Past tax numbering. Heyllave’s series starts where you configure it. Review fiscal identity and numbering before issuing the first document, not after.
- Payments already received. Do not re-record collections that happened elsewhere. What you bring across is each customer’s open balance, as a starting point.
- Inventory history. What you load is the current stock per location. The movement that produced it belongs to your previous system.
- Whatever your team looked up out of habit and nobody uses. A migration is the one cheap opportunity not to bring half the fields with you.
Before you call the workspace live
- A person with the intended role sees exactly what they should, confirmed with View as rather than imagined.
- A customer record and an asset record are related and findable from search.
- A stock-tracked item shows the right quantity at the right location.
- One complete case has been through request, work, document and payment.
- A notification rule reached a colleague, with the wording you expected.
- Public identifiers look the way you want them to look in two years.
If something doesn’t work
If an entity type rejects a field or a value, the problem is its schema, not your role. If you loaded records and they do not appear in search, check which fields you marked as indexed. If an item does not draw down inventory, check its category’s stock tracking before checking permissions. And if an identifier has already gone out wrong, do not try to fix it by renumbering: ask whoever administers the workspace what the path is, because those ids may already be in shared documents.