SuperOffice Online Replication allows customers to stream their CRM data from the SuperOffice cloud into their own infrastructure (SQL Server) in near real-time.
- Future-Proofing for Cloud: Legacy Mirroring is not supported in our new Azure Public Cloud (APC) environment. As SuperOffice migrates customers to APC, all Mirroring users must eventually switch to Replication to maintain access to their data.
- Real-Time Data: We are moving from scheduled batch updates (every ~20 minutes) to near real-time streaming. The new solution uses Change Data Capture (CDC) technology to stream changes immediately as they happen.
- Simplified Security: We are switching from a "Push" model to a "Pull" model. You no longer need to host a public-facing web service (WCF/IIS) or open incoming firewall ports. The new client sits safely inside your network and reaches out to us.
Who can join?
This pilot is designed for IT administrators and partners who are comfortable managing SQL Server infrastructure.
You are a good fit if:
- You currently use Mirroring: We specifically need existing customers to run this new client in parallel with their old solution to verify that the data is identical.
- You have SQL Server resources: You must provide a local SQL Server (or Azure SQL) and have a dedicated IT resource capable of installing Windows Services and configuring connection strings.
Allt Svar (1)
- Mirroring (Legacy): Operates on a schedule, transferring data in batches approximately every 20 minutes.
- Replication (New): Operates in near real-time. It utilizes SQL Server Change Data Capture (CDC) technology on the backend to continuously stream data changes exactly as they happen.
- Mirroring (Push): SuperOffice connects to your environment and "pushes" the data. This requires you to host a public-facing Web Service (WCF/IIS), maintain a valid SSL certificate, and open incoming firewall ports.
- Replication (Pull): You install a local client (a Windows Service) inside your network that proactively reaches out to SuperOffice to "pull" the data. This drastically simplifies security, as you no longer need to expose public endpoints or manage incoming firewall rules.
- Mirroring: Can generally pick up where it left off even if your local server is down for over a week.
- Replication: Data changes are buffered in a cloud queue (Kafka) with a strict 7-day retention limit. If your local client is offline for more than 7 continuous days, the data expires from the buffer, and you will be required to perform a full resynchronization from scratch.
4. Tables
The difference in the number of tables is completely normal and by design.
The new Replication system uses the same base list of excluded tables as the old Mirroring system, but it adds a few smart improvements to keep your replica database cleaner and faster. We removed about 58 tables that don't contain reporting data:
- Obsolete tables: We now filter out old, leftover tables from past system upgrades (these are usually named
OBSOLETE_...). - System dictionary tables: We no longer include internal system-definition tables, as they don't contain any actual customer data.
- Binary and Cache data: We excluded the
binaryobjecttable because it mostly contains internal cache and large files that aren't useful for a reporting database.