A SaaS migration in practice: switching over without losing a working day

On paper, a SaaS migration sounds like exporting, importing and switching off the old environment. The moment the daily operation cannot afford to miss a day, that picture falls apart. A trading company processing orders, an agency logging hours or a publisher managing subscriptions cannot improvise for two weeks. Replacing the application is rarely the hard part. The hard part is the data, the integrations, the permissions and all the exceptions that quietly became part of the process over the years.

So here is one real project rather than a checklist. A Dutch organisation with around 85 employees had spent eight years on the same cloud application for customer records, project planning and invoicing. Prices kept going up, the API was too limited to build anything decent on, and every monthly report was pasted together by hand from a handful of exports. Management wanted a more modern platform, but not at the cost of their history, their revenue or the patience of their own people.

The problem was not the software

On paper the switch looked simple. A new package had been chosen, creating users took an afternoon, and the new vendor offered an import function for customers and projects. The catch was that in eight years the old system had grown into the rest of the business.

Customer details came in through forms on the website. Project information was pushed to an internal planning tool. Finance had an integration with the accounting package. Account managers had added their own fields for contract terms, pricing agreements and renewal dates. On top of that sat hundreds of running projects, a healthy pile of duplicate customer records, and documents that had to stay attached to a case file without necessarily moving to the new platform.

So the first question was not whether the data could be exported. It was this: which processes have to demonstrably work at half past eight on Monday morning? That difference decides whether you are doing a technical job or guiding a change project.

Start by finding out how people actually work

Before anything got built, we picked the existing situation apart. Not just the database, but the work as people really did it. That turned up things you will not find in any manual.

Sales used a free text field for information that should have been structured, notice periods for example. Finance corrected certain invoices directly in the accounting package, which meant the old SaaS system had been wrong on those records for years. And the planning integration dutifully pulled data every hour, but only when one specific field was filled in exactly right. Forget that field and your project simply never showed up in the planning. Everyone had made peace with it.

That inventory produced a migration map: for every type of data, a decision to move it as is, clean it up first and then move it, archive it, or leave it behind. Every integration got an owner, a short technical description and a test scenario. Administrative work, granted. But it is how you avoid discovering a critical integration after go-live, usually through the person it hurts the most.

A deliberate choice: not everything came along. Closed projects older than five years were kept as a readable archive. Duplicate contacts were merged and unused fields disappeared. The new environment ended up faster and a good deal easier to work in.

Migrating three times before it counts

The technical approach came down to three rounds: a trial with a limited set, a full rehearsal with all the relevant data, and only after sign-off the real switch.

The trial was not just about counts. Of course the customers, projects and invoices had to add up. What mattered more was whether everything still hung together. Was each project still attached to the right customer? Were open tasks assigned to the right person? Did invoice lines recalculate correctly? And did a change made in the new system land properly in the accounting package?

The first round exposed a classic. A timezone difference shifted dates on part of the records by a day. For historical notes that is annoying. For contract end dates and invoicing moments it is unacceptable. We did not patch it by hand; we fixed the import logic, reloaded the same set and checked it again. Manual corrections never survive the next import anyway.

That is the entire reason trial migrations exist. An import that runs without an error message is not yet a successful migration. The result has to make business sense too.

Integrations are not a side issue

Plenty of migrations overrun because integrations are left until last. Here there were integrations with the website, the accounting package, the document storage and the internal planning tool. Each with its own authentication, its own error handling and its own assumptions about how a field should be filled.

The website integration ran in parallel during the rehearsal phase. For a few weeks new enquiries were sent to both environments, so we could compare what arrived without losing a single lead. For the accounting integration we chose a clean cut instead: no invoices went out during the migration weekend, and after go-live one colleague checked every transaction for the first few days.

Not every integration had to be rebuilt. The documents already lived in a separate document store, independent of the old SaaS package. That store simply stayed where it was, and the new platform links each case file to the right folder. Moving all of it across as well would have added weeks to the project for very little gain. You are allowed to make that kind of call, as long as you write it down.

The weekend of the switch

The final migration ran over a weekend. At four on Friday afternoon the old environment went read-only. Anything that came in after that was logged on a shared list following a procedure agreed in advance. Then came the last export, the import and the checklist that was already written.

Those checks were specific: record counts, revenue totals, outstanding invoices, permissions per user group, the main forms, and one test project walked end to end including its invoice. On Saturday afternoon people from sales, finance and operations went through their own daily routines in the new environment. Not as a casual demo but as an acceptance test, with sign-off.

On Monday morning everyone could get to work. There were questions about changed screens and a new way of working, but nothing that blocked anyone. The list of weekend changes was entered and checked that same morning. The old application stayed available as a read-only archive for another six weeks. Only once everything was running steadily, including the first full invoicing round, was the contract with the old vendor cancelled.

What it delivered, and what did not go right straight away

The result was more than a new package. The organisation had its data and its processes in one place again. Reports came straight out of the system instead of out of three exports and a spreadsheet. Leads arrived in a way you could verify. People saw only what they needed, and the financial figures lined up with the accounts.

It was not perfect on day one. Several reports were revised after go-live, because managers only discovered which breakdown they were missing once they started using them. Part of the user group needed extra explanation about the new workflow, and in hindsight we should have scheduled that before go-live rather than after. That comes with the territory. A migration is not a moment, it is a transition period.

The biggest win sat in the preparation. Because the processes, the data and the integrations were taken seriously up front, the technical switch stayed small and boring. In this line of work, boring is a compliment. It also helps when development, integrations and hosting sit with one party: one phone number when something needs adjusting, instead of three suppliers pointing at each other.

Is your organisation ready to migrate?

A SaaS migration is worth it when the current system slows growth, creates manual work or leaves you too dependent on one vendor. Switching purely because something more attractive is on the market is rarely a good reason. Look first at the processes the system supports, the quality of your data, and the systems it has to work with.

In a small, straightforward environment a standard import is fine. With custom processes, sensitive data, complex API integrations or hard availability requirements, a phased approach is the wiser choice. Then you want to know in advance who you call when data does not arrive, an integration falls over, or the go-live has to be rolled back.

The best migration barely feels like a project to the people using it. What they notice is that the work goes faster, the information is right, and problems do not sit around. That is where a system starts working for the business again instead of the other way round.