It's a question we still get asked when a client's ageing server is approaching end of life: replace it with another physical server, or move the workload to the cloud entirely? For the large majority of workloads we review, cloud wins clearly, on cost, resilience and maintenance overhead alone.

But 'always cloud' isn't quite universal advice yet. Businesses with very large local file sets accessed constantly by on-site CAD, video editing, or engineering software can still see genuinely better performance from local storage than from a cloud connection dependent on internet bandwidth, particularly in areas without the fastest connectivity.

Specific line-of-business software, older, bespoke applications not built with cloud deployment in mind, sometimes still requires local infrastructure, at least until a genuine replacement or migration path exists.

For everything else, and that's the majority of what we see, cloud infrastructure now wins on nearly every practical measure: no ageing hardware to replace on a five-year cycle, built-in resilience without a business having to build and maintain its own, and a cost model that scales with actual use rather than requiring a large upfront purchase for capacity that sits unused most of the time.

Precision manufacturing businesses across Brackley and Northampton, many supplying into the same motorsport and aerospace-adjacent engineering ecosystem that surrounds Silverstone, run production equipment that's often more network-dependent than the business realises until something goes wrong.

Modern CNC machines, automated inspection equipment and production-line monitoring systems increasingly pull data over the same network as the office, sometimes on the exact same switch as everyone's email and file access. A network outage in this environment doesn't just mean someone can't check their inbox, it can mean a production line stops.

The fix isn't necessarily more expensive hardware, it's correct network segmentation: production equipment on its own VLAN, properly prioritised, isolated from general office traffic so a laptop downloading a large file doesn't compete for bandwidth with a machine mid-cycle, and isolated from a security perspective so a compromised office laptop can't reach production equipment directly.

This is one of the areas where a generic, one-size IT setup genuinely underserves a manufacturing business, and it's usually visible within the first proper network audit we run for a new manufacturing client.

Of every security recommendation we make, a proper business password manager has the best ratio of cost to actual risk reduction, and it's the one we push hardest on with new clients who don't already have one.

The problem it solves is simple: password reuse across multiple accounts is still the single biggest reason a breach at one, unrelated service turns into a compromised business account elsewhere. A password manager makes unique, strong passwords for every account the path of least resistance, rather than something requiring genuine effort to maintain.

The business-tier versions add what individual, personal password managers don't: centralised policy control, the ability to instantly revoke access when someone leaves the business, and secure sharing of credentials for shared accounts without ever actually revealing the password itself to the person using it.

It's a small monthly cost per user, and it closes one of the most common, entirely preventable routes into a business account. There's no client we wouldn't recommend this to.

Both Microsoft and AWS operate UK-based data centre regions, and for most businesses, which specific data centre a given file physically sits in genuinely doesn't matter day to day. For a specific set of clients, though, it's a real compliance question worth getting right.

Businesses working with UK public sector contracts, healthcare data, or certain financial services requirements often have explicit obligations, contractual or regulatory, that data remains within the UK, or within the UK and EEA, rather than being processed on servers physically located elsewhere.

Both major Microsoft 365 and Azure UK regions, and AWS's London region, support this requirement directly, but it has to be configured correctly at tenant setup, not assumed by default, since some services and back-end processes can otherwise route through other regions for entirely legitimate technical reasons.

If data residency is a genuine contractual or regulatory requirement for a business, rather than a general preference, it's worth an explicit conversation and a documented configuration check, not an assumption that 'it's probably fine.'

Milton Keynes has been one of the UK's genuinely fast-growing business locations for years, and we see the IT consequence of that growth constantly: infrastructure that was entirely adequate at ten staff, quietly buckling somewhere around thirty, in ways that aren't always obvious until they're already a problem.

File storage is usually the first thing to strain, a shared drive or basic NAS that worked fine for a handful of people starts producing sync conflicts and slow access once a business is running twenty-plus concurrent users against it.

Wi-Fi is the second, and the least visible until it's acute: a single consumer-grade router or two, adequate for a small office, starts dropping connections and struggling with device density once headcount grows and everyone's carrying a laptop and a phone onto the network.

The third, and the one with the most serious consequences if missed, is access control: a business that's grown from a handful of trusted people who all had access to everything, into an organisation that genuinely needs role-based permissions, before someone who left eighteen months ago is discovered to still have access to the accounting system.

None of this needs solving all at once, and over-engineering infrastructure for a headcount a business hasn't reached yet wastes money just as surely as under-provisioning does. The useful exercise is a proper review at each real growth milestone, not a fixed schedule.

When we take on a client already running AWS infrastructure, cost review is usually the first exercise, and it's rarely a difficult one, since the same few patterns turn up in most accounts we look at.

Unattached EBS volumes, storage left behind after an EC2 instance was terminated but never actually deleted, are the single most common finding. They cost money every month for literally nothing.

Oversized instances running well below their provisioned capacity are the second: an instance sized for a launch-day traffic spike, still running at that size a year later. Right-sizing based on actual CloudWatch utilisation data routinely finds real, immediate savings.

The other three: reserved instances or savings plans not yet purchased for genuinely stable, predictable workloads; old snapshots never cleaned up; and data transfer costs from architecture that routes traffic less efficiently than it needs to between regions or availability zones.

None of these require re-architecting anything. They're a housekeeping pass, and they're worth doing on a schedule, quarterly at minimum, rather than only when a bill spikes unexpectedly and someone finally goes looking.

Simulated phishing campaigns, sent with client permission as part of ongoing security awareness training, give a genuinely useful read on where real risk sits in an organisation, and the results are consistently more interesting than the generic industry statistics suggest.

The templates that get the highest click rates aren't the obvious 'your account has been suspended' style emails most people have learned to spot. They're the ones that impersonate an internal colleague, referencing something plausible like an invoice query or a meeting reschedule, sent at a time of day when someone's moving fast through their inbox.

New starters click at meaningfully higher rates than established staff, which makes sense, they haven't yet built the instinct for what's normal versus what's slightly off inside a specific organisation's email culture. This is exactly why onboarding-stage security awareness training matters more than an annual refresher course everyone's forgotten by month three.

The most effective single change we've seen isn't more training content, it's shortening the feedback loop: someone who clicks a simulated phishing link and immediately sees a short, non-punitive explanation of what gave it away learns faster than someone who finds out weeks later in a training session.

Engineering and precision manufacturing firms supplying into the Silverstone motorsport corridor operate on genuinely different tolerances to most small businesses, and it shows up in what actually breaks their working day.

A CAD file that takes twenty minutes to sync between a design office and a production floor isn't merely annoying in this environment, it can be the difference between hitting a supplier delivery window and missing it, in an industry where race weekends don't move to accommodate a slow network.

We see this most often with businesses that have grown past their original network setup: a file server bought for five users now supporting twenty, or Wi-Fi coverage that was fine for an office and is now straining across an expanded workshop floor. The fix is rarely exotic, business-grade switching, correctly placed access points, and file storage that matches how CAD and design software actually reads and writes data, rather than how a generic office file share is configured.

It's also why we push metrics beyond simple uptime percentages for clients in this space: average file transfer speed, and Wi-Fi coverage mapped against the actual production floor layout, matter more here than they would for a standard office-based business.

A traditional VPN works on a simple assumption: once a device is connected, it's trusted, and can generally reach whatever's on the network behind it. That assumption made sense when everyone worked from one office, on company-owned devices, behind a firewall. It makes considerably less sense now.

Zero Trust architecture flips the model: nothing is trusted by default, including a device already on the network. Every request to access a file, an application or a service is verified individually, based on identity, device health, and context, not just network location.

For a hybrid team working from a laptop at home, a client site in Northampton, and the office in the same week, this matters practically, not just theoretically. A stolen VPN credential in the old model can potentially reach everything on the network. Under a Zero Trust setup built on Microsoft Entra Conditional Access, that same credential still has to pass device compliance and identity checks at every single step.

We're not ripping out every client's VPN overnight; a phased move, tenant by tenant, makes more sense than a disruptive cutover. But for any client refreshing their network setup from scratch, Zero Trust is now our starting recommendation, not traditional VPN.

The UK's PSTN (the traditional copper telephone network) is being progressively switched off nationally, and any business still relying on it for phone lines, alarm systems, or payment terminals needs a migration plan, not eventually, but on a specific timeline set by network providers.

VoIP (Voice over Internet Protocol) is the practical replacement, routing calls over the same internet connection already in the building rather than a dedicated phone line. Done properly, call quality is indistinguishable from a traditional line, and it opens up features traditional phone systems never had: calling from a laptop or mobile app under the same business number, call routing rules that traditional exchanges couldn't easily do, and detailed call analytics.

The migration itself needs planning around a few specific things: confirming the internet connection has sufficient bandwidth and priority for voice traffic (Quality of Service configuration matters here), checking anything else relying on the old line, alarm systems and card machines particularly, and porting existing phone numbers across without a gap in service.

Done as a planned project, this is a straightforward, low-disruption migration. Left until a provider forces the switch-off date, it becomes a rushed one, which is exactly why we're already having this conversation with every client still on a traditional line.

Microsoft's own Copilot marketing leans heavily on dramatic demos: summarising hour-long meetings, drafting entire reports from a one-line prompt. For the smaller businesses we support across Northamptonshire and Buckinghamshire, the genuinely useful day-to-day wins are quieter than that.

Copilot in Outlook drafting a first-pass reply to a routine enquiry, which someone then edits rather than writes from scratch, saves real minutes across a working week. Copilot in Excel explaining what a formula in an inherited spreadsheet actually does, without needing to track down whoever originally built it, solves a problem every small business has at some point.

Copilot in Teams summarising a meeting someone missed is probably the single most-used feature we see in client tenants, simply because it removes the awkward 'can someone catch me up' message that used to eat into everyone's afternoon.

It isn't free, and it isn't a replacement for training or process. But layered onto a Microsoft 365 tenant that's already properly configured and licensed correctly, which is where we start every Copilot conversation with a client, it earns its keep faster than most software purchases we see.

Microsoft Defender for Business, included in many Microsoft 365 Business Premium licences, has improved enormously over the past few years, to the point where recommending a separate, paid endpoint protection product for every client is no longer automatic.

For a business already on Microsoft 365 Business Premium, Defender for Business genuinely holds its own against dedicated third-party products on core detection rates, and it has a real advantage in integration: alerts, device compliance and Conditional Access all sit inside the same Microsoft ecosystem the rest of the tenant already runs on.

Where dedicated third-party products like Bitdefender GravityZone still lead is in deeper forensic detail during an active incident, more granular policy control across mixed device fleets, and centralised management for organisations running infrastructure across Microsoft, AWS and on-premise environments simultaneously.

Our honest recommendation depends on the client: a Microsoft 365-native business with straightforward device management is often well served by Defender for Business alone. A business with more complex, mixed infrastructure, or specific compliance requirements around endpoint forensics, still benefits from a dedicated product layered on top.

We get asked fairly often whether a business should be running its infrastructure on AWS or Azure. It's a reasonable question, and the honest answer disappoints most people: for a business already using Microsoft 365, Azure usually wins by default, not because it's technically superior for every workload, but because of how deeply integrated the identity and access layer already is.

Azure Active Directory (now Microsoft Entra ID) already governs who can access what across Microsoft 365. Extending that same identity boundary into Azure infrastructure means one set of credentials, one set of Conditional Access policies, and one audit trail, rather than stitching two identity systems together.

That said, AWS remains the right call in specific situations: a business with a bespoke application already built for AWS-specific services, a team with existing AWS expertise, or workloads that genuinely need a service AWS does better (certain container orchestration and data-analytics tooling, for instance).

We run both, and we'll tell a client honestly when Azure isn't the better fit, but for the majority of the Milton Keynes and Northampton businesses we support, the practical, cost-effective answer is the platform that already talks to the identity system your staff sign into every morning.

Cyber Essentials has gone from an optional government-backed scheme to something we're now asked about weekly, usually because a client's own customer is asking for it as a condition of doing business, particularly in public sector and supply chain contracts.

The certification covers five technical control areas: firewalls, secure configuration, user access control, malware protection, and patch management. It's a baseline, not a comprehensive security audit, but it's a baseline that genuinely blocks the most common, opportunistic attacks, which is the majority of what actually hits small businesses.

The self-assessment version (Cyber Essentials) is a questionnaire verified by an external assessor. Cyber Essentials Plus adds an independent technical audit of the same five controls, which is increasingly what larger contracts specifically require.

We prepare clients for both. The most common reason an assessment fails first time round isn't a dramatic security failure, it's something mundane like unpatched software still running past its support end-of-life, or an admin account still using a shared password across multiple systems. Both are quick fixes once identified, which is exactly why a pre-assessment review is worth doing before the formal one.

Northamptonshire has a strange claim to fame: within a fifteen-mile radius of Silverstone sit some of the most technically advanced engineering operations on the planet. Mercedes-AMG PETRONAS F1 is based in Brackley. Red Bull Racing is a few miles up the road in Milton Keynes. Aston Martin Aramco F1 sits right at Silverstone itself. This corridor, sometimes called Motorsport Valley, produces more Formula 1 engineering output per square mile than almost anywhere else in the world.

That doesn't mean every business in the area is running an F1-grade data centre, and we're not claiming any of the teams above as clients. But the standard those operations set filters down into the wider regional business culture in a real way: precision, low tolerance for downtime, and an expectation that systems simply work.

The businesses we work with across Towcester, Brackley and Silverstone itself are, more often than not, engineering firms, motorsport suppliers, and precision manufacturers who supply into that world. Their tolerance for IT that 'mostly works' is understandably low. A CAD file that won't sync, a supplier portal that's down on delivery day, or a VPN that drops mid-transfer costs real money in an industry where tolerances are measured in microns and timing in tenths of a second.

It's part of why we built Dragonfly IT the way we did: proactive monitoring that catches an issue before a user notices, sub-15-minute average response, and a local, on-site presence across the Northampton-Milton Keynes corridor for the moments remote support genuinely isn't enough.

Industry reports often quote average ransomware recovery times in the range of a few days. In practice, for a business without a tested disaster recovery plan, the real number is usually measured in weeks, not days, and the technical recovery is often the smaller part of that timeline.

The first phase is containment: isolating affected devices, establishing how the attacker got in, and confirming the backup copies themselves weren't touched. This alone can take longer than expected if network segmentation wasn't in place beforehand, since a single flat network means every device has to be individually checked.

The second phase is the actual restore, which is only as fast as the last tested backup allows. A backup that's genuinely 3-2-1 compliant, with an immutable offsite copy, can mean systems back online within hours rather than days.

The part most business owners underestimate is the third phase: notification obligations under UK GDPR if personal data was affected, communication with clients and suppliers, and the operational knock-on of staff unable to work normally throughout. This is the phase a tested incident response plan actually shortens, not the technical restore itself.

The single biggest predictor of how bad a ransomware incident gets isn't the sophistication of the attack. It's whether the business had already rehearsed what happens in the first hour.

We're confirming Dragonfly IT's status as an official Microsoft Cloud Solutions Provider (CSP). It's a Microsoft-audited accreditation, not a self-declared badge, and it changes the practical shape of how we support Microsoft 365 and Azure for clients across Milton Keynes, Northampton and the surrounding area.

In practice, CSP status means we hold the licensing relationship directly with Microsoft on our clients' behalf. There's no third-party reseller sitting between a support call and a fix. When a mailbox needs a licence changed, a Conditional Access policy needs adjusting, or a tenant needs migrating, we can action it ourselves in minutes, rather than raising a ticket with a distributor and waiting.

It also means we carry direct responsibility for getting configuration right first time; Microsoft's CSP programme includes its own support and competency requirements, which we now sit inside rather than alongside.

For anyone running Microsoft 365 without a managed IT partner, or migrating from an on-premise Exchange server, this is the point of contact worth having in place before the next licence renewal lands in an inbox.

Ask most business owners if they're backed up, and the answer is yes. Ask them when they last actually restored a file from that backup to confirm it works, and the answer is usually silence.

The 3-2-1 rule is the industry baseline for a reason: three copies of your data, on two different types of storage media, with one copy held offsite in a genuinely separate location. It sounds simple, and it is, but each part closes a different failure mode. Two local copies on the same server rack don't help if the building floods. A single cloud copy doesn't help if that account itself is compromised by ransomware that's been sat quietly in the network for weeks, encrypting backups along with everything else.

This is where a lot of 'backup' setups quietly fail: the backup software is running, the job shows green, but nobody has tried a real restore in over a year. We run Acronis Cyber Protect specifically because it combines the backup layer with active ransomware detection, meaning it can spot and block an encryption attempt on the backup files themselves, not just the live data.

If it's been more than six months since anyone actually tested a restore, that's not a backup strategy, it's an assumption. Worth checking before the day it actually matters.

Multi-factor authentication is the settings change everyone talks about, and rightly so. But in the Microsoft 365 tenants we take on, we consistently find the same three settings left on their defaults, each one a genuine gap.

The first is SPF, DKIM and DMARC configuration on the domain's own DNS records. Without these correctly set, it's trivial for an attacker to send an email that appears to come from your own domain, straight into a client's inbox, asking for an invoice to be paid to a new account. We check this on every new client tenant, and it's wrong more often than it's right.

The second is Safe Links and Safe Attachments in Microsoft Defender for Office 365, which re-check a link or a file at the moment someone actually clicks it, not just when the email first arrived. A link that was clean an hour ago can be weaponised the moment before someone clicks it; this setting is the difference between catching that and not.

The third is simply disabling legacy authentication protocols on the tenant. Older protocols don't support MFA at all, so an attacker with a leaked password can walk straight past multi-factor authentication entirely if legacy auth is still switched on somewhere in the tenant. Most organisations don't actually need it any more, and turning it off closes a door most people don't know is open.

None of these require new software or additional licensing in most Microsoft 365 plans. They're a configuration exercise, not a purchase, which is exactly why they're worth checking today rather than after an incident.

We still find a genuine number of Northamptonshire and Buckinghamshire businesses running an on-premise Exchange server, usually because it 'still works' and nobody wants to disturb it. The problem isn't whether it works today. It's what happens when Microsoft's support window for that version closes.

Once a server version passes end of extended support, security patches stop. That's not a theoretical risk; unpatched Exchange servers have been a favoured target for exactly this reason, since a known vulnerability with no fix becomes a permanent open door.

Migrating to Exchange Online as part of Microsoft 365 removes this problem entirely, since Microsoft manages the patching, uptime and security of the underlying platform. The migration itself, done properly, involves a genuine project: mailbox migration, mail flow cutover, and a period running both systems in parallel to catch anything the migration missed.

Done in a planned window, over a few weeks, it's a manageable project with minimal disruption. Done in the fortnight after a server finally fails outright, it's a crisis, done under pressure, with no fallback if something goes wrong. If there's still an on-premise Exchange server anywhere in the business, the time to plan the migration is now, not after it breaks.