For a South African food distribution business built around a custom mobile ordering platform, the application is not a supporting tool, it is the primary sales channel. Between 80 and 90 percent of daily revenue flows through it. When the developer who had built and maintained that system passed away unexpectedly, the client was left with a working platform that nobody could meaningfully touch. What followed was eighteen months of careful groundwork before a private cloud hosting migration could safely take place, which was then completed within a two-hour window with zero orders lost.
The Challenge: A Business-Critical Platform No One Could Modify
Customers log in, browse pricing, place orders, and manage quantities entirely through the platform. When the original developer passed away, the client was left with a working system that meaningful development was no longer possible on. Critical fixes required ad hoc developers parachuting in to address individual issues without understanding the broader architecture.
The synchronisation tool that connected the app to the company’s on-premises accounting system — the coordinator of every order processed — existed only as a compiled executable. No source code was accessible. No one could modify it. When sync errors occurred, the only resolution was a manual restart. Si Futures had been providing that restart service, on standby around the clock, for the better part of eighteen months.
A development company capable of taking over a platform in this state was eventually identified, but it took nearly a year and a half to bring the codebase to a point where it could be properly supported. The next challenge was migrating the client from shared Si Futures infrastructure to their own dedicated private cloud infrastructure — without disrupting a business that operates around the clock.
Approach: Tracing Every Packet Before the Window Opened
Rudie de Vries, Si Futures Cloud Service Manager, took personal responsibility for the client’s business continuity from the moment the situation became clear. That meant developing a thorough understanding of every component of the platform, not just the hosting infrastructure but the application architecture, the synchronisation workflows, the firewall rules and the dependencies between each system. If anything failed, he needed to know what backups were required, which services to restore first, and in what sequence.
When the development team completed their rebuild and confirmed a migration date, comprehensive pre-migration checks were conducted before the window opened. The methodology was deliberate: treat every component as a packet and trace its path. Where does it originate? Where does it need to go? What stands between those two points? That systematic process identified several connection failures the development team had not caught — gaps that would have surfaced during the migration itself had they not been resolved first.
The migration window was set for 10am to 12pm on 7 April, 2026. The timing was deliberate. That two-hour period represents the quietest point in the business cycle for a company taking orders for next-morning delivery. Starting later in the day would have compressed the client’s ability to fulfil the backlog created by downtime, disrupting deliveries scheduled for the following morning. The window was chosen to protect business operations, not simply to minimise technical complexity.
Solution: Private Cloud Migration With Zero Margin for Error
The migration moved the client from a shared hosting environment to their own dedicated virtual machines within the Si Futures private cloud. The platform comprises an NGINX front-end server handling incoming connections, an IIS layer running the application API, MS SQL on shared infrastructure retained for licensing cost efficiency, and what is now a HangFire job scheduler — a full rebuild of the synchronisation tool that had previously existed only as an unmodifiable executable.
Pre-checks had already identified that the new virtual machines lacked direct access to several components of the client’s infrastructure, and that external IP addresses on the dedicated virtual machines were not included on vendor allowlists. Both were resolved before the window opened.
During the migration, three additional issues emerged. The first was a routing inefficiency: the NGINX front-end was resolving the application URL externally, sending every API call out to the internet and back rather than routing directly between servers on the same network. With thousands of API interactions driving every user session, that single misconfiguration was adding latency to every click. A local hosts entry on the Linux server resolved it during the migration window.
The second was product images. The development team had not transferred 13,000 product images to the new server. Their estimate for the transfer was six hours — a timeline that would have required abandoning the migration entirely. The NOC team was contacted immediately, temporary firewall rules were opened, and the images were copied across the internal network in three minutes.
The third was Azure App Registration credentials on the new environment that did not match the previous configuration. Si Futures had retained those credentials, identified the mismatch, and resolved it before it caused any disruption.
The migration completed within the two-hour window.
Outcome: A Stable, Developable Platform — and a Commercial Milestone
The cutover completed on schedule with zero orders lost and no disruption to the client’s fulfilment operation. The synchronisation layer that had required manual intervention for eighteen months now runs independently, with job status visible through the application and the ability to resolve conflicts internally rather than through an emergency call to Si Futures. Sync performance improved immediately following the migration to HangFire jobs.
The development team now has full pipeline access to continue feature development and bug resolution — something that had been impossible for eighteen months. The client confirmed the result was a significant improvement and that the new environment represented the way the platform should have been operating from the start.
The client is already rolling out additional features to their customer base, including improved search functionality that was impossible to deploy before the rebuild. For a business where the app is the primary sales channel, a stable, developable, and properly monitored platform is not an IT milestone. It is a commercial one.
What Made the Difference: Preparation, Proximity, and Response
The development team had produced a detailed deployment plan. What they had not done was test it thoroughly. On a platform where the vast majority of business revenue is at stake, the distance between a plan and a tested plan is not a minor detail.
Pre-migration checks traced every connection that would need to function in the new environment — not assuming that configuration documented on paper translated to configuration that worked in practice. That approach identified allowlist gaps and port issues before the change window opened, reducing the number of surprises during the migration itself.
When surprises did occur, the response was immediate. A six-hour image transfer became a three-minute internal copy because the NOC team was available and firewall access could be granted and revoked within minutes. A routing inefficiency degrading every user interaction was caught and corrected during the same window.
The role Si Futures played throughout was that of a technical translator and operational safety net — bridging the gap between the development team’s application knowledge and the infrastructure knowledge required to make everything work together. Providing virtual machines and stepping back would not have been enough. Understanding how every component of the platform fits together, and being ready to act when individual parts did not perform as documented, is what made the migration succeed.
On a platform where the business runs entirely through a single application, the gap between a deployment plan and a tested deployment plan is the gap between a successful migration and a failed one.
Client Impact
The client confirmed that the new environment represented a significant improvement, describing the outcome as the way things should have been done from the start. Sync performance improved immediately following the migration, and the stability of the rebuilt platform means the development team can now deliver feature updates rather than managing an environment they could not change.
The client is actively communicating those improvements to their own customers, with enhanced search functionality among the first updates made possible by the newly accessible codebase. For a business where the app is the primary sales channel, a stable, developable, and properly monitored cloud solutions environment is not an IT milestone. It is a commercial one.
Is Your Business-Critical Application Running on Infrastructure It Has Outgrown?
If your organisation depends on a custom application or platform that has outgrown its hosting environment — or if a migration is overdue — Si Futures can help you plan and execute it without disrupting the operations that depend on it. Contact our team to discuss private cloud hosting and application infrastructure support.
