The State of the UK Removals Software Market 2026

Before I run through the market itself, and I will, vendor by vendor, in the next piece, I want to do something first that nobody bothers to do. I want to set out, plainly, what this software actually is underneath the marketing. What you are really buying beneath the login. Who is really responsible for your data. And who carries the risk when it all goes wrong on a Monday morning.

Because most software comparisons are feature bake-offs, and I want to be honest about why you won't get one of those from me. I couldn't write a fair one if I tried. I own one of these products. If I sat here scoring everyone's features against each other, tallying who has what, it would be gloating dressed up as analysis, and you'd be right to see straight through it, because there's no honest version of a feature comparison, written by anyone, that doesn't come out flattering the person who wrote it. So I'm not going to insult you with one.

Everyone has a website, everyone demos. You can see a feature with your own eyes. Nobody chooses the software that runs their entire company off the back of a document, they choose it after seeing it work, in a demo, in their own hands. So the features will take care of themselves. What you cannot see with your own eyes, what no demo really shows you and no brochure ever mentions, is what sits underneath all of it. The architecture. The infrastructure. Who is actually responsible for your data when it matters. That is the part I can genuinely help with, because that part is fact, the same fact whoever describes it, and it is the part that decides whether a system serves you or quietly becomes a liability.

So this first piece is the definitions and the debunking. Read it even if you skim everything else, because it is the bit that lets you see through everyone's marketing. Including mine.

And on that: one thing up front, so there is no confusion. This is our marketing. Moovi is my company, and I am not going to pretend otherwise. But I am not writing this as the CEO of Moovi. I am writing it as someone who has spent his life in both of these worlds, this industry and technology, and who can speak about both with some confidence. When I get to the market in Part Two, every claim about every other product will be drawn from public sources, and those sources listed so you can check them. Where I speak well of Moovi, weigh it exactly as you would weigh anything a founder says about his own product. That is the deal, and I think it is a fairer one than this industry usually offers. But this first piece names no products at all. It is just the truth about the technology, so you can judge all of them, me included, for yourself.

What you are actually buying, underneath - two ends of three spectrums

Web-based versus thick-client

A web-based application, sometimes called web-native, is one you open in a browser, on any device, and you are in. Nothing to install. You could log in from a laptop in the office, a phone in a customer's hallway, or a tablet on the warehouse floor, and it is the same live system every time.

A thick-client application is a program that is installed and run on a Windows computer. It lives on the machine. To use it somewhere else, you either install it on that machine too, or you remotely connect into a computer that is running it.

Both can be perfectly good software. The thick-client approach is long-established, and on the machine it is installed on it can feel quick and solid. But it ties you to Windows, it usually has to be installed and maintained on each machine or reached by remote access, updates have to be pushed out, and mobile is rarely a first-class citizen, it is normally a bolt-on. Web-native, by contrast, runs anywhere there is a browser, needs nothing installed, and updates for everyone at once the moment the provider ships a change.

Neither is automatically "better" in the abstract. But one of these was designed for how software is delivered today, and the other for how it was delivered twenty years ago. When you understand which one is in front of you, a great deal of the rest falls into place.

Self-hosted versus cloud

This is the one that sounds harmless and isn't. "Self-hosted" tends to get described as "we just run it on our own server," as though that were a small thing. It is not a small thing.

Self-hosting means you buy the server. You house it. You power it. You cool it. You give it a reliable internet connection. You back it up. You patch it and update it. You license the operating system and the database it runs on. You replace the hardware every few years when it ages out. And, above everything else, you secure it, which is not a job you do once but a discipline you maintain forever: access control, encryption, monitoring, patching, and staying ahead of threats that change every single week, for a machine that happens to hold your customers' home addresses, their full household inventories, and the precise dates their houses will be sitting empty.

And if that server falls over at nine o'clock on a Monday morning, in the middle of your busiest week, it is your problem to fix. Not the software company's. Yours.

Cloud means that entire burden, the hardware, the power, the connectivity, the backups, the patching, the resilience, the security, is carried by the provider whose actual job that is. You are not running a data centre in a cupboard. You are renting the outcome, "the software works, the data is safe, and it is there when I reach for it," and letting someone whose whole business is keeping that true, keep it true.

In-house versus outsourced development

In-house means the people who build and maintain the software are the software company's own staff. Outsourced means that work is handed to a third-party agency.

And here is a distinction most buyers never think about, but should. What we loosely call "the software" is really three distinct areas, each needing genuinely different skills, and each often handled by completely different people:

• The application, the software itself, the thing you log into and use.
• The infrastructure, the servers, networks, databases and cloud environment it all runs on.
• And, sitting over both of those, cybersecurity, the discipline of keeping the whole thing, and your data inside it, safe.

A vendor might build the application in-house and outsource the infrastructure. Or outsource the application but keep security in-house. Or outsource all three, to three different companies. Or none. These can, and often do, sit in entirely different hands.

Both models, in-house and outsourced, can ship perfectly good software. But they behave very differently the moment you need something changed, and I say this from sixteen years working inside and alongside exactly the kinds of companies this work gets outsourced to. When development is in-house, a change is a conversation with the people who build the thing. When it is outsourced, in my experience it is rarely a phone call worked through with the team. It runs through steps: an initial call, a scoping call, internal calls on their side that you never see, a statement of work, revisions to that statement of work, contract negotiation, a purchase order, and only then, after all of that, does development actually begin.

And let me be clear about what outsourcing does not mean: it does not mean the engineering is any less good. It often isn't. What it does mean is that every change, every piece of innovation, is likely to have to travel through that process, and that an outsourced team makes its money doing exactly this work. So changes tend to carry a cost to the software company, and costs, in the end, have a way of finding their way back to you. That is not a flaw in anyone's character. It is simply how the model is built, and it is worth understanding before you buy.

The thing nobody tells you: these burdens do not disappear

Here is the point that ties all three definitions together, and it is the single most important thing in this piece.

None of this stops mattering when you buy software as a service. The backups still have to happen. The security still has to be maintained. The server, wherever it is, still has to stay up. The system still has to be reachable from wherever your people are working. The hardware still ages. The threats still evolve. All of it still has to be done.

With a server in your office, the answer is you. All of it, you. With a thick-client system you host or remotely connect into, largely you. With software built and run by three different outsourced companies, it is spread across parties you have never met and cannot ring directly.

And with cloud software as a service done properly, your responsibilities shrink to almost nothing. Two things, really: your internet connection, and the device in front of you. That is it. You do not buy a new server every three years. You do not power it, cool it, license it or update it. You do not configure incremental backups and hope they ran, because the provider is taking a continuous backup for you and can fail over automatically if something goes wrong. You do not lie awake wondering whether the box in the cupboard has been patched against this week's threat. You do not worry about business continuity, about resilience, about whether you can connect from a customer's house two hundred miles away, or about whether you have just been hacked. None of it. Because that entire category of cost, effort and risk has been lifted off your business and placed onto the shoulders of the people whose job it is to carry it.

That is a huge part of what you are actually buying. Not features on a screen. The removal of an entire discipline, an entire liability, and an entire recurring cost, from your company. When you come to compare the products, in Part Two, keep asking yourself the real question underneath every one of them: when the hard part goes wrong, whose problem is it?

A word on evidence, and on what silence tells you

When I do run through the market, everything will be built on publicly available evidence, a vendor's own technical documentation, its own live product, its partners' public statements, and Companies House. Where a company documents itself openly, I will describe it with real confidence. Where the public evidence is thin, I will say only what I can source, and draw no conclusions I cannot support.

But it is worth saying plainly, now: how much a company is willing to show you in the open is, itself, information. A platform that publishes its technical documentation for anyone to read is telling you something about how it operates. A platform where almost nothing is publicly verifiable is telling you something too. Neither is proof of quality on its own. But if I were choosing where to put my business, and my customers' data, the amount a vendor was willing to show me in daylight would be one of my very first questions.

The one opinion I will allow myself

Everything above is as factual as I could make it. So let me allow myself the single piece of editorial freedom in this whole series, one sentence, flagged clearly as opinion rather than fact, so you can take it or leave it.

After sixteen years in enterprise technology, I'll tell you this: the more separate parties you have involved in building, running and securing the software your business depends on, the more people there are to point fingers at each other when something goes wrong on a Monday morning, and the longer you will wait, standing in the middle of your busiest day, for it to be fixed.

That is the only opinion I am going to give you. Everything else stays on the record.

The questions I would ask every single vendor

If I were running a proper enterprise procurement for software in this industry, and given the operational complexity of a removals and storage business, the absolute need for stable access on the day, and the genuinely sensitive nature of the data we hold, home addresses, inventories, empty-house dates, these are the questions I would put to every company, mine included. Not a different set for each, to suit an argument. The same questions for all of them. And in Part Two, that is exactly what I am going to do.

1. Is your software web-native, something I open in a browser on any device, or a Windows application I install or remotely connect into?
2. Is it cloud, where you carry the servers, or self-hosted, where I do?
3. Who builds and maintains the application itself, your own staff, or an outside agency?
4. Who manages the infrastructure it runs on? And who is responsible for cybersecurity? Are those the same people, different people, or different companies again?
5. When I need something changed or fixed, what actually happens? Is it a conversation with the people who build it, or does it go through scoping, a statement of work and a purchase order first?
6. How are backups handled, and how often? If something fails at the worst possible moment, what happens, and how long until I am working again?
7. Can my people use it, fully, from anywhere, a customer's home, the warehouse floor, the road, or only from certain machines or a certain office?
8. Does it run my whole operation on one connected record, or is it one part of the business with other systems and spreadsheets bolted around it?
9. Have you carried out genuine enterprise deployments, and migrated businesses off legacy systems onto yours, and can you speak to how that actually goes?
10. Do you operate across multiple regions or countries, with my data held in the right place, and do you have the in-house expertise to even answer questions three, four and six properly, or is the honest answer "I'd have to ask someone"?
11. And a simple one that tells you a great deal: how often is development work chargeable?

Hold those eleven questions in your head. In Part Two, I am going to walk the entire UK market, from the most focused tool to the platform that runs everything, and put every one of these questions to every one of them. Including us. And I look forward to showing you all of ours, if we have the time.

The answers, as you will see, differ enormously.