Bringing a Register You Already Have
Nobody adopts an asset register with no assets. The interesting part of a migration is never the file format — it is the four columns you have that the destination has nowhere to put, and deciding in advance which of them you are prepared to lose.
The position, stated first
Import the identity, the location, the custody and the ownership — all four are first-class here and all four survive. Do not attempt to bring accumulated depreciation, purchase order references or funder tags through the importer, because there is nowhere for them to land. Decide that before you build the file, not after the load fails.
Every asset register migration begins the same way: somebody exports the old system, opens it in a spreadsheet, and discovers it has forty-one columns. The work is not moving them. The work is deciding which nine matter.
What the importer is
It is a validated write path, not a raw loader — and that distinction is the useful thing to know about it. The ownership field, for instance, is validated in five separate places in this codebase, and the bulk importer is one of them. A file containing a value that is not owned, leased or borrowed is rejected there exactly as it would be on the form.
That is worth more than it sounds. An importer that bypasses validation is how a register acquires a thousand rows nobody can filter, and it is the default behaviour of most bulk loaders.
The four things that survive
Identity
Tag, name, category, serial, purchase date and cost. The spine of the register, and the part every source system has.
Location
Where it belongs. Import your locations first — a register loaded against locations that do not exist yet is a register you will re-import.
Custody
Who holds it, as an assignment. Movements from the old system do not come across; this is a starting position, not a history.
Ownership
Owned, leased or borrowed, validated on the way in. Most source registers do not have this column at all, which makes the migration the moment to decide it.
Accumulated depreciation
Nothing computes or holds it. It stays in the schedule it came from.
Purchase order and supplier
No relationship exists on an asset, so no import can populate one. A custom field is the honest destination.
Project, grant or funder
Same reason. If donor reporting matters, this is the column to plan for as a custom field before the load.
Movement history
The new register starts on the day you load it. Old movements stay in the old system, which is a reason not to switch it off.
A migration is a decision about what you are willing to lose. Deciding it in the spreadsheet is cheap; discovering it in month three is not.
The order that avoids a second load
-
Locations first, and get the hierarchy right
Assets reference locations. Loading assets against locations that do not exist yet produces a register you have to correct row by row, and the correction is manual because the relationship is already wrong.
-
Categories second
Small, quick, and the thing every subsequent filter depends on. A register with one category is a list.
-
Decide the custom fields before the assets
Purchase order, supplier, funder — whatever your old register held that this one has no home for. Create them first and the import fills them; create them later and you are back in the spreadsheet.
-
Load a hundred assets and stop
Filter them, verify a few physically, print a label, scan it. A hundred rows will surface every mapping error the full file has, and correcting a hundred is an afternoon.
-
Then the rest, then the custody positions
Assignments last, because they are the most likely to have changed between the export and the load — and the easiest to fix individually afterwards.
The column nobody thinks about until later
Ownership. Most source registers do not have it, because most were built by finance and finance already knew everything on the list was owned. So the migration is the first moment anybody is asked, per asset, whether it is yours.
That is an annoying question to answer for four hundred rows and a very useful one to have answered. It is also the only chance you will get to do it as a bulk exercise rather than one asset at a time forever afterwards. Default the column to owned, then go and find the leases.
Do not switch the old system off
The movement history does not migrate — not because of a limitation in the file format but because the new register has no concept of a movement that happened before it existed. Keep the old system readable for as long as anybody might ask who had something in a year you no longer cover.
What AWRA OpsHub does today
- A bulk asset importer that validates on the way in, sharing the ownership rules enforced on the create and update forms and the API.
- Import of identity, category, location, purchase details and custody position.
- Custom fields on assets, which are the destination for source columns this product has no relationship for.
- Locations and categories as separate, importable reference data.
What it does not do
- Accumulated depreciation, net book value or any depreciation state. There is no engine to hold it.
- Movement history from a previous system. The register begins the day it is loaded.
- A purchase order or supplier relationship on an asset, so no import can populate one.
- A project, grant or funder relationship on an asset.
- Any reconciliation report between an imported file and the resulting register.
Not ours, by choice
- The importer being a validated path rather than a raw loader is a real strength, and it means a badly-shaped file fails loudly rather than quietly producing unfilterable rows.
- The four unimportable things above are all consequences of relationships that do not exist on an asset, not of the importer. No file format would change them.
- Nothing here is Colombian. Colombia is here because the buyers for an asset register are established businesses with an existing one, and the migration is the first real conversation.
What is not built for your market today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in your market. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If the seam to a clearance provider, a supplier invoice that can be read, a limit that is not an amount, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
Which end of the document you stand at, and what the limit is written in
Three builds cover most of what this region exposes, and the first is a seam rather than a system. Document exchange with the authority runs through a role somebody is accredited for, so what we build is the two-way join to the provider you pick — our document handed over in the shape they expect, and the reference, status and any acknowledgement written straight back onto our record, which is what turns "which of ours are not yet cleared" into a report rather than a reconstruction. Second, reading a supplier's electronic invoice into lines that carry tax, so the purchase side holds a rate and not only an amount. Third, a limit expressed as a multiple of an index unit rather than as a sum of money, with something that actually reads the unit when it is revalued. All three are data-model changes rather than settings, and we would quote them as such.
Local payment rails, and obligations that fall on the buyer
Statement feeds and local payment rails wired into the Payments Register, alongside the buyer-side obligations this region is unusual for — an acknowledgement generated from a receiving event and transmitted, and a report of purchases received but not yet acknowledged. Receiving against the order already runs; the outbound half is the buildable part on top of it.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
A local payroll engine with income tax tables and social security contributions computed on live employee records, producing returns in the layout your authority expects rather than rebuilt each month.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedFour questions before you build the file
Which columns in my export have no destination?
A good answer sounds like
A specific list, before the load.
What it actually means
The whole migration, in one question. Ours are depreciation, order, supplier, funder and history.
Does the importer validate, or does it just insert?
A good answer sounds like
It validates, using the same rules as the form.
What it actually means
A raw loader gets your data in and your filters wrong, and the discovery is months later.
What happens to a row that fails?
A good answer sounds like
It is reported, and the rest load.
What it actually means
All-or-nothing loads on a four-hundred-row file mean one bad date costs you the afternoon.
Can I load a hundred and look before committing?
A good answer sounds like
Yes, obviously.
What it actually means
If the answer is no, the migration plan needs a test tenant, and that is a different conversation.
Map the columns before you export
If you have a register and are wondering what survives the move, send the column headings. That is a twenty-minute answer and it is a much better first conversation than a demonstration.
Talk about migrating a registerFrequently asked questions
Can I re-import to correct a mistake?
Corrections are best done as updates rather than a second load, because a re-import against existing tags is how a register acquires duplicates. This is the argument for loading a hundred rows first.
What do I do with net book value from the old system?
Keep it in the depreciation schedule, which is where it will continue to live — nothing here computes or stores it. The register and the schedule stay two documents, reconciled at year end.
Should I bring dormant or disposed assets across?
Generally no. A retired asset in the new register is a row that will be counted, filtered and verified against forever. Bring what exists; keep the rest readable in the old system.
