Switching your TMS in a running transport company is a bit like changing the engine of a truck while it drives. Orders come in every day, drivers are on the road and accounting sends invoices to KSeF. It can be done without downtime, but only with a plan that decides upfront what you move, when you switch and who owns each part.

This guide is for companies already working in some TMS and thinking about moving to another one. We do not compare specific products here: the focus is the move itself, meaning data, schedule, training and invoicing.

When is switching your TMS worth it, and when should you stay?

The usual reasons to move are very practical. The team works around the system, keeping part of the work in spreadsheets and chat apps, so the data in the TMS is incomplete.

The software does not fit how you work, for example orders with several loading points or splitting an order into legs handled by different carriers.
Invoicing and KSeF require retyping data between systems.
You cannot see the margin on an order until accounting closes the month.
You track driver and vehicle document deadlines in a separate calendar.
Every configuration change means a ticket to the vendor and a long wait.

There are also cases where moving makes no sense. If the real problem is missing training or badly set permissions, new software will just carry the same mess to a new place.

Your peak season ends in a few weeks and the team is already at full stretch.
The current contract runs for a long time and the early termination fee is high.
Nobody in the company has time to own the rollout.
The missing features could be switched on in your current system, but nobody has checked.

Before you sign a new contract, write down five situations from last month where your current software let you down. If most of them come from configuration, talk to your current vendor first.

Which data should you move so dispatch works from day one?

TMS data migration is not about copying everything the old system holds. You move what you need to take and settle the order that comes in tomorrow morning, and you archive the rest.

Contractors: Tax ID, addresses, contacts, payment terms, credit limits. Remove duplicates and companies inactive for years while you are at it.
Fleet: Tractors and trailers with registration numbers, EURO norm and trailer type.
Drivers and documents: Registration certificates, inspections, insurance and driver documents, always with an expiry date. A scan with no date will never warn anyone.
Open orders: Everything on the road or planned after the switchover date, with rate, carrier and driver.
Price lists and rates: Fixed client and carrier rates on your most common routes.
Invoice numbering: The last number in each series, so the new system continues it with no gaps or repeats.
Open balances: Unsettled receivables and payables on the switchover date, with invoice numbers and due dates.
History: Closed orders and old invoices are usually fine to keep in an archive export.

When moving orders and contractors, start with a trial import on a small sample, for example twenty companies and ten orders. You will see straight away whether postcodes, currencies and payment terms land in the right fields.

If you move to Sokar, we help you bring over your contractors, fleet and orders. You can also add a new contractor by tax ID and pull the company details from the Polish GUS register, so there is no retyping of addresses.

How do you get your data back from the current vendor and not miss the notice period?

The first document to read is the contract with your current vendor, not the offer from the new one. It decides when you can leave and in what form you get your data.

The notice period and the date by which you must give notice so the contract does not renew automatically.
Export format: spreadsheet, CSV or a database dump, and whether it covers every table, including documents and attachments.
Whether the export costs extra and how long it takes to prepare.
How long you keep read access to the old system after the contract ends.
When and how the vendor deletes your data after termination.

Run a full export before you give notice and check that you can actually open it. If something is missing, it is much easier to sort out while both sides still want a good relationship.

Driver and contact details are personal data. Your new TMS vendor processes them on your behalf, so you need a data processing agreement with them under Article 28 of the GDPR.

TMS implementation step by step: a plan built around the switchover date

The key decision in the whole project is the switchover date: the day from which new orders go only into the new system. Pick a day with normal volume, ideally at the start of a month, so monthly settlements are not split across two programs.

1Name a rollout owner: one person from dispatch who has the time and the authority to decide.
2Set the switchover date and check that it fits the notice period of the old contract.
3Configure the new system: branches, users, roles, invoice series, currencies and payment terms.
4Run a trial import on a small sample and fix the field mapping.
5Run the full import of contractors, fleet and documents with expiry dates.
6Train the team on a copy of real orders from the past week.
7On switchover day, move open orders and set the opening balances.
8For the first two weeks, collect issues from the team every day and fix them on the spot.

How long does it take? In a small or midsize company the whole move usually fits within a few weeks, from first configuration to the end of parallel running. Cleaning the data takes most of that time, not the import itself.

Example schedule around the switchover date

Four weeks before: Data export, contractor cleanup, configuration of the new system.
Two weeks before: Trial import, training for dispatchers and accounting.
One week before: Full import, test invoice issued and sent to KSeF.
Switchover day: New orders only in the new system, open orders moved across.
Two weeks after: Closing old orders, reconciling balances, switching off the old invoice import.

This is an example for a company with around fifteen vehicles and a few forwarders. At a larger scale the stages stay the same, only data cleanup and training take longer.

How do you run two systems in parallel without doing everything twice?

Parallel running is safe only when every order has one home. The simplest rule: orders taken before the switchover date are finished where they started, and new ones go only into the new software.

Never enter the same order in both systems, or within a week nobody will know which record is current.
Invoice an order in the system where the order lives.
Long orders that will run for weeks should move to the new system on switchover day.
Agree in advance on the day the old software becomes read only.

Who needs training, and on what, so the team does not drift back?

A single training session for the whole company rarely works. Each role needs a different handful of screens and should practise them on its own real orders.

Dispatcher: driver planning, statuses, vehicle documents with deadlines.
Forwarder: from client order to carrier, rates, margin, sending the order by mail.
Accounting: invoices, compensations, payments, carrier invoices and KSeF.
Drivers: how to confirm a status and send the CMR from a phone.
Owner: permissions, profitability reports, KSeF settings.

In Sokar every user gets one role: owner, dispatcher, forwarder, accounting, carrier or fleet safety, so each person sees only what they need. Drivers install nothing: they open a link on their phone, see the load and route, confirm the status and upload the CMR.

What happens to KSeF and invoice numbering when you change software?

Under Polish VAT law an invoice must carry a sequential number within one or more series that identifies it unambiguously (Article 106e(1)(2) of the VAT Act). When you change software you have two safe options: continue the current series from the next number, or open a new series with a clearly different label.

Example: if the last invoice in the old system is FV/10/2026/148, the new system starts at FV/10/2026/149. Never let both programs issue invoices in the same series, not even for a single day.

Structured invoices you issued earlier stay in KSeF, which stores them for 10 years from the end of the year of issue (Article 112ba of the VAT Act). You do not need to migrate them, and you can issue a correction to an old invoice from the new system by referring to its KSeF number.

Grant the new system its KSeF permissions before switchover day and send a test invoice.
Switch off the purchase invoice import in the old system so the same carrier invoices do not reach accounting twice.
Once parallel running ends, revoke the permissions or token of the old system.

In Sokar the account owner switches on the KSeF integration in settings. You send invoices to KSeF straight from the order and import purchase invoices from KSeF with the issue and receipt dates filled in automatically.

For your specific situation, consult a tax advisor. It is also worth warning your accounting office before you change invoice series.

How to change your freight forwarding software without chaos: a checklist

Notice period checked and the deadline for giving notice written down.
Full export from the old system, opened and checked.
Data processing agreement signed with the new vendor.
Rollout owner and switchover date agreed.
Contractor database cleared of duplicates.
Fleet and documents imported together with expiry dates.
Last invoice numbers in every series noted and set in the new system.
Open balances reconciled with accounting on the switchover date.
KSeF integration switched on and tested with one invoice.
Every role trained on real orders.
The one home per order rule known to the whole team.
Old invoice import switched off and old system access limited to read only.

Planning to switch your TMS? The Sokar team helps move your contractors, fleet and orders, and in the demo we will show you what your work looks like after the switch.

Book a demo