The decision to move Bellwether Property Group's core systems to the cloud had been deferred three times before chief financial officer Marcus Okafor finally pushed it through in late 2023. The Sydney-based commercial property management firm had 12 servers in a leased data centre rack, a legacy property management platform that had not received a major update since 2019, and an annual IT infrastructure bill of $340,000 covering hardware maintenance, data centre fees, and a support contract with a reseller that had changed hands twice in four years.
The migration took six months. It cost $210,000 in professional services fees and temporary parallel-running costs. And it very nearly went badly wrong in the final fortnight.
"We had scoped the migration around our main platform," Okafor recalled at a CIO roundtable hosted by ISACA Australia in April 2025. "What we had not fully mapped was the number of small integrations — lease document generation, an invoicing module, a reporting tool that fed into our board dashboards — that all depended on the on-premises environment. Three days before cutover, we found seven integrations that needed rewriting."
The MSP managing the migration, Newcastle-based firm Cloudbridge Partners, had a team available to work through the weekend. The cutover proceeded with a two-week delay, not a crisis. Had Bellwether attempted the migration without dedicated migration support, Okafor estimates the firm would have gone live with broken integrations and faced weeks of manual workarounds during one of its busiest periods.
Why migration projects fail
Research by Gartner consistently places cloud migration project failure rates — defined as projects that significantly exceed budget, timeline, or both — at between 30 and 50 percent for organisations without prior migration experience. The failure modes are well-documented: underestimated application dependencies, misconfigured security settings that create data exposure, cloud cost structures that were modelled incorrectly during planning, and insufficient testing before cutover.
Application dependency mapping is perhaps the most common blindspot. Enterprises accumulate integrations over years — APIs, scheduled scripts, file share connections, database links — and these connections are rarely fully documented. A competent pre-migration assessment from an experienced MSP will map these dependencies systematically, often revealing integrations that the IT team was unaware of or had forgotten.
Security misconfiguration is the other consistent failure mode. On-premises environments accumulate security controls over time. Network firewalls, access control lists, and data classification practices that evolved organically on-premises do not transfer automatically to cloud environments, where the shared responsibility model places explicit obligations on the customer to configure storage buckets, identity and access management policies, and network security groups correctly. IBM's 2024 Cost of a Data Breach report found that cloud misconfiguration was the initial attack vector in 14 percent of Australian breach incidents — the third most common entry point overall.
The assessment phase determines everything
Experienced MSPs treat migration projects as beginning not with technical work but with a structured assessment phase that can run four to eight weeks for organisations of significant complexity. The output is a migration strategy document that categorises applications using a standard framework — typically the "6 Rs": rehost (lift and shift), replatform, repurchase, refactor, retire, and retain.
Not every application belongs in the public cloud. Some workloads with high data sensitivity or specific latency requirements are better suited to a private cloud or hybrid architecture. Some applications are candidates for retirement rather than migration — a migration project often surfaces legacy software that has long since been superseded but continues running because no one has formally decommissioned it. Bellwether retired four applications during its assessment phase, simplifying the migration scope considerably.
Cloud cost management as ongoing discipline
The post-migration phase is where organisations most commonly experience disappointment relative to expectations. Cloud cost models — consumption-based pricing for compute and storage, egress fees, licence costs for managed database services — are structurally different from the capital expenditure model they replace, and require active management rather than passive acceptance.
Bellwether's first cloud invoice, for the month following full cutover, was $28,400. The projected monthly steady-state cost in the business case had been $19,000. The gap was attributable to over-provisioned virtual machines — the MSP had sized them conservatively for the initial period — and storage costs that had not been correctly accounted for. Cloudbridge Partners ran a rightsizing analysis in the second month and implemented reserved instance commitments for predictable workloads. By month four, the monthly bill had stabilised at $21,200, within 12 percent of the original model.
Okafor's assessment now, 18 months post-migration: the firm's annualised infrastructure spend has fallen from $340,000 to approximately $255,000, the platform is receiving regular updates for the first time in years, and the disaster recovery capability — previously a theoretical annual test that consistently found gaps — is now tested automatically each fortnight through a cloud-native replication and failover configuration.
"The savings are real," he said. "But the thing I didn't anticipate was how much the reliability improvement would matter. We used to have two or three significant outages a year. We haven't had one since."