Switching Project Management Software: A Checklist

Thinking about switching project software? The biggest worry is rarely the new software. It is the data: years of client history, tens of thousands of logged hours, and an invoice ledger that has to keep adding up to the cent. That is a fair concern, but not a reason to stay put. With a structured approach the switch takes two weeks, of which only one weekend is genuinely tense. Here is the checklist.

First: is switching the answer?

Three reasons are good enough to justify the effort: you are missing functionality that affects how you run the business (cost tracking, capacity planning, e-invoicing), you are structurally overpaying for what you use, or you cannot get at your own data. See what project software costs for an honest comparison on that second point.

One reason is not good enough: dissatisfaction with how something looks. A migration costs your team attention either way, and a package that is prettier but does the same thing does not deserve it.

Step 1: decide what has to come along

Inventory each data type and why it needs to move.

Whatever does not need to move, archive as an export on your own storage. You will probably never need it, but the cost of keeping it is close to zero and the cost of discarding it is unknown.

Step 2: pull the data through the API, not through spreadsheets

Almost every modern package has a REST API that lets you retrieve all entities including the references between them. That is fundamentally better than separate spreadsheet exports, in which precisely what you need disappears: which hour belongs to which service of which project, and which invoice it ended up on.

If you cannot reach an API at your current vendor, that in itself is informative. Take it along as a requirement for your next choice, because otherwise the next migration will be just as hard. What to look for is covered in choosing API-first software.

No API available? The spreadsheet route works too, provided the new package offers an import template with a sample file per data type and the import can be repeated safely.

Step 3: run a trial migration and verify three totals

This is the step that makes the whole switch safe, and the one most often skipped.

A good migration is idempotent: you can run it again without creating duplicates, because every imported record remembers where it came from. That means you can rehearse without risk.

Run the import as a trial first, then check exactly three numbers against your old package:

1. The count of organisations, people and projects. A discrepancy means a filter or a limit is active that you did not expect.
2. The sum of logged hours per year. Not the grand total, but per year: that way you immediately see whether a period is missing.
3. The sum of invoice amounts per year, excluding VAT. This is the number your accountant will ask about.

If those three match to the cent and to the hour, your migration is complete. If one does not, the year-by-year breakdown tells you where to look. In a real migration of an agency with 437 contacts, 394 projects and 15,601 time entries, that meant verifying two figures: 21,792.92 hours and €1,302,069.26 in invoices, both exactly equal to the source.

Step 4: deduplicate when merging administrations

If you merge two environments, the same client is almost certainly in both. Match in this order: company registration number, then VAT number, then email address, then name. Have edge cases reviewed by hand rather than merged automatically. An incorrectly merged contact is far harder to repair than a duplicate.

Also watch for employees present in both administrations and for project numbers that overlap.

Step 5: stop your imported hours from being invoiced again

This is the trap that causes the most trouble, and it is surprisingly easy to avoid.

You import historical hours that were invoiced long ago in your old package. If the new package then assembles draft invoices from every unflagged hour, Monday morning brings tens of thousands of euros in invoices your clients have already paid.

The answer is an invoicing cut-off date: a date before which the new package never invoices. Everything before it is history, everything after it is work still to be billed. Set that date to the day of migration and verify on your first invoice run that nothing predating it slipped in. In Horixa this is a setting under company details, applied automatically during import.

The same logic applies to payment reminders: imported invoices without a due date must never trigger an automatic dunning letter to a client who already paid. Keep reminders switched off until you have run your first invoice cycle.

Step 6: choose a quiet go-live

Migrate at the end of an invoicing period, preferably over a weekend. The runbook:

• Friday 17:00: everyone completes their hours in the old package. From that moment it goes read-only.
• Friday evening: final import, with the same three verification totals as the trial.
• Saturday: create users and link them to employees, set permissions, configure integrations (accounting, calendar, email).
• Monday 09:00: the team logs into the new package. Half an hour of instruction, no more.
• The following month: the old package stays available read-only. Only cancel that subscription after you have run one full invoice cycle in the new one.

That last rule is not excessive caution but simply cheap: one month of subscription costs less than a day of searching.

Step 7: the first four weeks

Schedule three checkpoints.

After week 1: has everyone logged hours? Missing hours in the first week are almost always a login or permissions problem, not reluctance. Check that the timesheet works for everyone, including on a phone.

After the first invoice run: is every invoice number, VAT line and amount correct? Compare that first run line by line against what you would have sent from the old package. This is the moment when finding a mistake is still cheap.

After week 4: are the balances still equal? Leave balances and work in progress are the two items that can quietly drift if anything was still booked in the old package during the migration.

The checklist in short

• An inventory of what moves, with a reason per data type
• Retrieval through the API, or through import templates with sample files
• A trial migration with three verification totals: counts, hours per year, invoice amounts per year
• Deduplication on registration number, VAT number and email, with edge cases handled manually
• An invoicing cut-off date set, payment reminders temporarily off
• Go-live at the end of an invoicing period, old environment read-only
• Users, permissions and integrations configured before Monday morning
• Three checkpoints in the first four weeks

How this works in Horixa

The import module follows exactly this approach. It reads your current environment through its API, first shows a verifiable trial import with totals, deduplicates on registration number and email address, and can merge two environments into one administration.

Without API access you upload everything as Excel or CSV, spread across twelve import cards: organisations, people, employees, projects, services, hours, leave, absence, opportunities, invoices, purchase invoices and costs, each with a downloadable sample file. That route is idempotent too: rows that already exist are skipped, so you can safely repeat the upload until the totals match. Data migration is included in every plan, with no upfront project fee.

What each plan includes is on the pricing page, and the full feature set is on the features page.

Frequently asked questions

How long does switching project software take? For an agency of up to 50 people, two weeks of elapsed time is realistic: one week for inventory and trial migration, one weekend for the final import and go-live, then four weeks with the old package running read-only as a safety net.

Can I bring my logged hours and invoices? Yes. Hours, invoices, projects, contacts and leave balances are all transferable, provided you retrieve them through an API or a structured import. The references between them matter more than the individual records.

What happens to invoices that were already paid? They come along as history, but you set an invoicing cut-off date so the new package never bills them again. Also switch off automatic payment reminders until you have run your first own invoice cycle.

Do we have to move everything on one day? For hours and invoicing, yes. Running two systems side by side sounds cautious but leads to hours in two places and an administration that cannot be reconciled afterwards. The old package does stay available read-only.

What if my old package has no API? Then use its export function and import through templates. In that case check the references especially carefully: which hours belong to which project and service is exactly what separate exports drop.

Does data migration cost extra? That varies by vendor; some charge an upfront project fee. At Horixa migration is included in every plan. Ask about it explicitly when comparing, because it is an item that can easily differ by several thousand euros.

---

Want to see whether your data comes across cleanly first? Try Horixa free for 14 days and run a trial import, or get in touch to walk through it together.