In 2012, we embarked on a journey to develop what would become Opuz12, a comprehensive solution for our internal group and clients. At the time, we followed the best practices of the industry, deploying standalone instances of Opuz12 for each client. The system was robust and innovative, but as technology evolved and our clients’ needs grew, we knew we needed to modernise. Our latest generation of Opuz reflects that leap forward, utilising a multi-tenancy architecture that has fundamentally reshaped how we deliver value.
However, the transition to this modern architecture wasn’t as simple as flipping a switch. We knew many of our clients would need to continue using the legacy system while simultaneously exploring the benefits of the new platform. This led us to one of the key challenges in our infrastructure upgrade - allowing seamless interaction between the legacy system and the multi-tenancy Opuz platform. We needed to build something that could enable this fluidity while preparing us for future scalability.
The Legacy System Bottleneck
Under the original setup, each client’s instance stored files—such as images and documents—directly in the web folders of their respective systems. The latest generation of Opuz introduced a much more efficient structure, but the legacy system’s file storage mechanism became a bottleneck. To maintain compatibility, any time a new client was onboarded to the modern Opuz, we had to spin up a legacy system instance just to handle the file storage and retrieval.
Diagram 1
This dual-system setup not only added unnecessary complexity but also posed long-term challenges in terms of performance, cost-efficiency, and operational management. We knew that the future of Opuz required a cleaner, more scalable approach, but we also had to ensure a smooth, uninterrupted user experience for clients still using the legacy system.
The Solution: Blob Storage and Virtual Path Mapping
Our solution was a dedicated blob storage space for each client. This wasn’t just about creating a new file storage mechanism—it was about carefully migrating all the files that had been stored within the web folders of the legacy apps into this new, secure storage environment. Each client now had a dedicated space to store and retrieve their files, ensuring scalability and security as we continued to grow.
To maintain compatibility between the legacy and modern systems, we developed APIs within the new Opuz platform that could read and write files using the same path structure as before. More importantly, we introduced virtual path mapping to "trick" the legacy apps into thinking they were still interacting with their original folders. In reality, these files had been migrated to external blob storage, but from the legacy system's perspective, nothing had changed.
Diagram 2
This approach allowed us to:
- Eliminate the bottleneck of needing a legacy system instance for every new client
- Simplify scalability, ensuring that our infrastructure could handle growing demand
- Maintain seamless user experience, allowing users to switch between legacy and modern systems without disruption.
- Eliminate the dependancy on the old system, allowing us to switch off the legacy apps when our clients are comfortable
- Improve performance as the blob storage APIs have a higher bandwidth
A Future-Ready Infrastructure
Our infrastructure upgrade wasn’t just about fixing an immediate bottleneck—it was about setting the stage for continued innovation. The introduction of blob storage and virtual path mapping has allowed us to build a foundation that is scalable, efficient, and forward-thinking. As our clients continue to transition to the latest generation of Opuz, we’re confident that our infrastructure will grow with them, seamlessly accommodating new demands and unlocking future potential.
This upgrade reflects our ongoing commitment to delivering the best possible experience for our clients while embracing the technologies of tomorrow. We’re proud of the progress we’ve made, and we’re excited about where this journey will take us next.
