REMOTE SITE CLOUD —
READINESS CHECK.

Yes, and that's the point most cloud migration advice skips. A traditional on-site server keeps working when the internet drops — staff can still open files and run the line-of-business system. Move everything to Microsoft 365 and every one of those functions now depends on the link staying up. That's not a reason to avoid the cloud; it's a reason to treat the connection itself as critical infrastructure and plan redundancy, local caching and a genuine offline fallback before the migration, not as an afterthought once staff are already stuck.

There's no single number that works everywhere — a five-person office and a forty-person depot with shift changes have very different requirements, and the honest answer depends on headcount, which applications are in use, and how much of the work involves large files or video. Rather than chasing a generic minimum, size the connection against this specific site's real peak concurrent usage: everyone syncing, calling and uploading at once. That's the actual test, and it's one most sites have never run.

It's still workable, but the plan has to be different. Sites without a fixed-line option need to lean harder on redundancy (a second, genuinely independent wireless path), on offline-capable applications, and on deliberately configured local caching so staff aren't waiting on the link for every file they open. Frontrow doesn't pretend a satellite or mobile-only site behaves like a fibre-connected office — the design has to be built around the connection that's actually available, not the one a generic brochure assumes.

Sometimes, but only as a deliberate, documented decision — not because nobody got around to decommissioning it. A local server can be the right call at a site with a genuinely thin or unreliable link, provided someone has actually worked out what it protects, how it's backed up, and what the plan is to retire it once the connection improves. The risk isn't keeping a server; it's keeping one nobody has assessed and everyone has quietly forgotten is load-bearing.

Schedule it for a low-activity window and tell the site in advance, then deliberately take the primary connection offline and time how long it takes the backup path to pick up the traffic. Run it the same way you'd run a fire drill — planned, observed and documented — rather than waiting for a real outage to be the first test. A failover that's only ever been configured and never actually pulled is a hypothesis, not a working control.

If the phone system is fully cloud-based with no fallback, calls stop the moment the link does — inbound callers get nothing, and staff can't call out. That's a bigger problem than a dropped file sync, particularly at sites where a phone is how customers, drivers or field staff reach the business. The fix is a documented fallback such as mobile forwarding or an alternate number, tested in advance so staff know what to do rather than discovering it mid-outage.

It should. Wet season affects two things at once: the physical connection, which faces more weather-related faults, and the support model, since road access for a technician to attend can be cut for days at a time. A readiness plan built only around a dry-season assumption will fail exactly when it matters most. That means testing failover and reviewing attendance timeframes against wet-season conditions specifically, not just assuming the arrangement that worked in June still holds in February.

A general IT health check usually assumes a standard office connection and asks whether the Microsoft 365 tenant is configured well. This assessment asks the question underneath that one: can this specific site's connection, redundancy and support model actually carry cloud-first working at all? It's the site-level, connectivity-first lens a generic tenant review doesn't cover, and it's the one that determines whether the tenant configuration will hold up once staff are relying on it every day.

A review of the specific site rather than a generic checklist: what connection is actually installed and how it performs under real load, what redundancy exists and whether it's been tested, what still depends on local infrastructure, and what a realistic support and attendance model looks like given distance and conditions. The output is a practical readiness view the business can act on before committing to a migration, not after staff are already working around a connection that can't carry the load.