THAT SERVER IN THE CUPBOARD!

There's a particular kind of server I've come to recognise. It was bought in 2016 or 2017 (if you've been in this game as long as me, maybe even 2000, right after the great Y2k project!), it lives in a cupboard or under somebody's desk, and its fan is louder than it used to be. It runs the finance system, the file shares, and something built for the business years ago that nobody would quite know how to rebuild.

The thing about this server is that it works. It has worked for so long that nobody can remember the last time it didn't, which is exactly why it's still there. Kinda like the firewall that's been managing your internet connection since 1998 and that no one dares turn off or upgrade! Every so often someone raises moving it to the cloud, and the conversation ends the same way it always does: yes, we should, at some point ...

I wrote last week about the data businesses are already sitting on. This one is about where that data is sitting, which turns out to matter just as much.

I've got a lot of sympathy with "at some point", because most of the reasons behind it are good ones. Working is underrated. Migrations have a reputation for costing more and taking longer than the quote said, and it's a reputation that's been earned. The business isn't an IT business and has no wish to become one. And nobody has a spare pound note 😁 for a project whose main selling point is that everything carries on working, just somewhere else.

I'll add one more, since I spend a good part of my working life making cloud bills smaller: the cloud is not automatically cheaper. It can be, if you treat it properly, and it's noticeably more expensive if you don't. If that were the whole picture, I'd probably leave the server where it is too.

What's changed over the last couple of years is that it isn't the whole picture any more. Nearly every conversation I have now starts with AI and ends up, usually within about ten minutes, being about where the data lives.

Someone wants an assistant that answers questions about their customers, or reads the contracts before a renewal. All perfectly sensible. Then we ask where the contracts are. On the file server. Where's the customer history? In a database on the same box, which only talks to the office network, and which nobody is allowed to connect anything new to because the last time someone did, it broke. So the AI pilot turns into an exercise in exporting spreadsheets by hand, and that is where AI pilots go to die.

Meanwhile, and this is the part that ought to worry people more than it does, the staff aren't waiting. They're pasting customer emails and chunks of documents into whatever free chatbot is on their phone, because that's the only AI they can actually reach. You end up with all of the data protection risk and none of the benefit.

Then there's the bit nobody enjoys, which is that standing still is a decision too. It just doesn't come with an invoice. A few of the things quietly building up around that server:

• The hardware is out of warranty, so when a disk fails the plan is "see what's on eBay".
• The operating system stopped getting security updates a while ago. Cyber Essentials asks about that, and so does the cyber insurance renewal form these days.
• The backups go to a drive next to the server, and nobody has tested a restore since, well, ever.
• The one person who understands it has a leaving date, even if they haven't announced it yet ... or has already retired without a decent handover.

None of this causes a problem this week. One of them eventually will, and it will be a Friday afternoon.

The other warning is about doing it badly. Copying the old server as-is into the cloud and leaving it running 24 hours a day, at the size it was bought at, usually costs more than the cupboard did. You've gained a bigger bill ... but you do have a nicer-looking fan! Moving properly means looking at what's actually on the box: some of it belongs in a managed service, some should be replaced by something off the shelf, some should be switched off because nobody has used it since 2021, and a bit of it might be fine where it is for now.

Once the data is somewhere reachable, with proper permissions around it, the AI conversation changes completely. On AWS, where we do most of our work, the AI models run in the same place as your data and under the same controls, rather than your data being sent off to someone else's service. Who can see what is managed in one place, so an assistant that answers questions about customers only answers from what the person asking is allowed to see. That's most of the GDPR conversation handled by design rather than by policy. You can try something for a month and switch it off if it doesn't earn its keep, instead of buying a server to find out.

So where do you start? Not with "the estate". Pick the one system that's in the way of the thing you actually want to do, which is usually the file server or the one line-of-business database. Move that properly, connect the AI to it, and answer one useful question with it. If it works, you've got a reason and a template for the next bit. If it doesn't, you've found out for a few weeks' effort, and the old server is still humming away in the cupboard where you left it.

If you've got a server somewhere that everyone is a bit nervous about, and you suspect it's the reason the AI ideas keep stalling, I'm happy to have a chat about what moving it would actually involve, what it would cost to run afterwards, and whether it's worth doing at all. No charge for the conversation, and I'll tell you honestly if I think you should leave it exactly where it is.

Roy Long, skyPurple Cloud