Freight Forwarding Software: The IT Questions to Ask Before You Commit

Freight forwarding software: two hosting models, two different dependencies

Forwarding systems come either hosted by the vendor and reached over the internet, or installed on a server in your office. Vendors present this as a preference. It is actually a decision about which single point of failure you would rather own, and it should be made deliberately.

Vendor-hosted means your dependency is the internet connection. The vendor handles servers, patching, backup and availability, which is genuinely less work for you, and in exchange an outage on your line stops the whole office. On-premises means your dependency is a server you own: nobody can take the system away, and you are responsible for keeping it patched, backed up, powered and cooled, forever.

Neither is wrong. What is wrong is picking one without preparing for its failure mode. A firm choosing vendor-hosted and running a single internet line has not made a choice, it has made a bet. A firm choosing on-premises without a tested restore has done the same.

A third option appears occasionally: the vendor hosts, but you also hold a local copy of the database for reporting or continuity. That is a reasonable arrangement where it is offered, though it is worth confirming how current that copy is and whether it is usable on its own or only as raw data.

Connectivity is the thing most firms underprovision

For a vendor-hosted system, connectivity is not infrastructure, it is the application. That reframing changes what is reasonable to spend. A second internet line from a different provider with automatic failover costs a fraction of a day's lost operations, and forwarding offices lose a day's operations more easily than most businesses because the whole team works inside one system.

Ask the awkward question when ordering: by what physical route does each circuit reach the building. In Dubai towers two circuits frequently share a riser or a street duct, which means one contractor's digger takes both. Where routes genuinely cannot be separated, a cellular link is the honest diverse path.

Failover belongs on the firewall, configured and tested, rather than as a manual step performed under pressure. Test it by unplugging the primary and watching what happens to a live session in the forwarding system, because a failover that drops every session is a different product from one that holds them. Our office network setup page covers the build.

One more thing worth measuring rather than assuming: how the system behaves on a poor connection rather than a failed one. Many forwarding platforms degrade badly on high latency, becoming unusable well before the line actually drops, which means the failover threshold that matters is not zero but somewhere above it.

• Treat connectivity as part of the application, not as overhead.
• Ask each provider for the physical route, not the product name.
• Configure failover on the firewall and test it against a live session.
• Where risers are shared, cellular is the genuinely separate path.

Integration is where implementations overrun

A forwarding system rarely works alone. It needs to exchange data with customs and trade systems, with carriers and airlines, with accounting, and often with customers who want status updates automatically. In Dubai that means Dubai Trade for most transactional work, Dubai Customs behind it, and for air cargo the electronic documentation standards maintained by IATA.

These integrations are where timelines slip, because each has its own format, credentials and quirks, and because vendors quote them optimistically. The questions worth asking before signing are specific: which of these integrations are already built and in production with other UAE customers, which would be new development, and what happens to the timeline if a portal changes its interface mid-project.

Ask for a reference customer in the UAE running the same integrations. A vendor with genuine local deployments will provide one readily, and a vendor without them has just told you something important about how your implementation will go.

Budget time as well as money. The pattern we see is that the licence is signed against a three-month implementation and the integrations take six, with the difference absorbed by staff running two systems in parallel. Asking which integrations are already built is really a question about which half of that timeline you are buying.

Who owns the data, and can you actually get it out

Your job files, rates, customer records and documents are the business. The question of whether you can retrieve them in a usable form is easy to establish before signing and extremely difficult to resolve afterwards, when the relationship has soured and you have nothing left to bargain with.

Get three things in writing. What format an export is provided in, whether that includes attached documents or only the database records, and what it costs. A vendor who can answer immediately has thought about it. A vendor who becomes vague has told you the answer.

This is not about distrust or planning to leave. Vendors are acquired, products are discontinued, and businesses change requirements. The firms that suffer are the ones who discover at that point that ten years of job files can be exported only as a series of PDFs with no index.

Ask also where the data is physically held, because a forwarder holding customer commercial terms and shipment values may have contractual obligations about jurisdiction. It is a question with a one-line answer from any competent vendor, and an uncomfortable silence from the others.

Accounts, and why shared logins cause real problems

Forwarding operations frequently run on shared logins, both in the forwarding system and in the customs portals, because it was simpler when the accounts were created and because licence costs encourage it.

Two consequences follow. First, nothing is attributable: when a declaration is questioned, you cannot say who submitted it, which is a weak position with an authority. Second, a departing employee retains access until someone changes a password for everyone, which in practice means the change is deferred.

Use named accounts wherever the system allows, and where licensing genuinely makes that impractical, record the fact so the risk is known rather than invisible. Our employee offboarding checklist covers the process side of removing access cleanly.

Agreeing who supports what

The most common operational frustration in forwarding IT is not an outage, it is an argument about whose outage it is. The vendor says the network is slow, the IT provider says the application is slow, and the operations manager watches a working day disappear while two suppliers disagree politely.

The prevention is a written split agreed at the start. The vendor owns the application, its updates and its data. The IT provider owns the network, the connectivity, the devices and, where the system is on premises, the server and its backup. Both agree what evidence looks like, which in practice means the IT provider has monitoring capable of demonstrating what the network was doing at the time.

That monitoring is the part firms skip and then need. Without it, a dispute is two opinions. With it, it is a graph. Our managed IT support service includes it as standard for exactly this reason.

Put a name to each side, not just a company. A support boundary that says the vendor handles the application means little at eight in the morning when the person who understands your configuration is not the person answering the queue. The firms that resolve these quickly are the ones with a named contact on both sides.

What happens when the system is unavailable

Every forwarding operation should have a documented answer to this, and most discover they do not have one during the first significant outage. The answer does not need to be elaborate: which jobs can proceed on paper, where the current rate sheet exists outside the system, who tells customers, and how the work is reconciled afterwards.

Write it down and keep a copy outside the system, which sounds obvious and is routinely got wrong. A continuity plan stored only in the application that has failed is not a plan.

Test the assumption once a year by asking the operations team what they would do. If the answer is that they would wait, that is useful information about how much the redundancy in the earlier sections is worth to you.

Keep the rate sheet question in mind particularly. A forwarder whose current buying rates exist only inside the system cannot quote during an outage, which turns a technical problem into a commercial one within hours. A weekly export to a file somebody can open is a crude answer that works.

A short list to take into the vendor meeting

Ask where it is hosted and what happens to our office if that connection fails. Ask which UAE integrations are already in production and with which customers. Ask what an export of our data contains, in what format, and at what cost. Ask whether named user accounts are practical at our licence level. Ask what your support boundary is and what you expect our IT provider to own.

Those five questions take ten minutes and will tell you more about the next five years than a feature demonstration will. A good vendor answers them directly and has answered them before. Our IT support for freight forwarding companies page covers how we set up the infrastructure side once the choice is made.

Take the answers away and compare them in writing rather than from memory. Two vendors that demonstrated equally well will usually separate cleanly on these five points, and the one that answered them without hesitation is generally the one whose implementation runs closer to its estimate.

If you are about to sign, we will review the IT side of the decision before you do: whether your connection and backup can carry the hosting model, who will hold admin accounts, how your data gets out if you leave, and what the vendor's support actually covers against what your office will be left to handle. You keep the written findings whichever system you choose. The same thinking applies to any business software you depend on, and you can send us the shortlist to start.

Frequently asked questions

Written by Srinivasan Ramachandran, Founder, Listonics · Published Sep 28, 2026 · Last reviewed October 13, 2026 · 2,107 words