ZigSig, a digital mortgage closing and notary platform, needed multiple primary/replica database clusters and web application nodes migrated from Jelastic PaaS to CloudStack IaaS. Because live signing sessions could not be interrupted, the migration had to preserve replication, application connectivity, TLS, access controls, and data integrity throughout a same-day cutover.
ZigSig’s platform runs multiple database clusters and web application nodes that support time-sensitive digital mortgage closings and notarization sessions. In this environment, a dropped connection during an active signing is more than a temporary inconvenience — it can disrupt a legally sensitive transaction, affect session continuity, and create compliance risk.
That meant this could not be treated like a standard cloud or database migration where a short maintenance window was acceptable. The migration had to preserve live application availability, database connectivity, active user sessions, and transaction integrity throughout the cutover, making zero-downtime migration planning a core requirement from the start.
A Jelastic database migration often changes the underlying network architecture. Firewall rules, security groups, private networking, database access, and application-to-database connectivity should be reviewed and rebuilt for the target cloud environment rather than copied without validation.
For primary/replica database clusters, the migration is not only about moving data. Replication health, synchronization, failover behavior, database roles, and cluster connectivity must remain intact so the new environment continues operating without introducing data loss or unexpected failover issues.
Jelastic environments can contain dependencies on internal DNS resolvers, private IP addresses, service endpoints, environment variables, and platform-specific networking. These references need to be identified and updated during migration to prevent latency, broken connections, or intermittent database and application failures after cutover.
Six Constraints That Had to Be Solved Together
ZigSig ran multiple primary/replica database clusters, so the migration had to preserve replication health, synchronization, and failover behavior — not simply copy database rows to a new environment.
Active digital closings and notarization sessions determined the migration window. Cutover timing had to be coordinated around real production activity so no in-progress signing session was interrupted.
A certificate failure during an e-signing workflow could immediately disrupt a live transaction. Every client-facing domain and subdomain therefore required TLS and certificate validation before DNS cutover.
For a compliance-sensitive platform, existing firewall and security rules could not simply be carried over. Firewall rules, security groups, and access controls had to be reviewed and rebuilt for the new cloud environment.
Some nodes still referenced Jelastic internal DNS resolvers. If left behind, those stale references could introduce multi-second latency after migration, so DNS configuration had to be identified, cleaned up, and validated on every node.
Because ZigSig’s database clusters and web application nodes were tightly connected, this could not be handled as a long phased migration. The database clusters, web nodes, networking, security, and application dependencies had to move together within the same-day cutover window.
Preserve Replication. Validate Every Dependency Before Cutover.
Rather than relying on a fresh dump-and-restore, we resynced ZigSig’s primary/replica database clusters on the new infrastructure. This preserved the existing replication and failover topology while minimizing the risk of data loss during migration.
The migration window was coordinated around ZigSig’s actual closing and notary schedule. Web application nodes were moved during a verified low-activity period so active e-signing and notarization sessions remained uninterrupted.
We verified the complete TLS certificate chain for every client-facing domain and subdomain before changing DNS. This ensured secure connections were working correctly before production traffic reached the new environment.
Instead of carrying years of accumulated firewall rules into the new cloud environment, we rebuilt security groups, firewall policies, and access controls based on ZigSig’s current requirements.
Stale Jelastic DNS resolver entries were removed from every migrated node and DNS resolution was validated on the new infrastructure. This eliminated hidden latency and ensured application requests were no longer dependent on the previous platform.
Multiple database clusters and all web nodes were cut over the same day, with zero data loss and no interruption to any active closing session. For a platform where every session carries a legal timestamp, that's the only outcome that counts as a success.
"Our database clusters and web nodes migrated seamlessly without interrupting a single legal closing session. The execution was flawless."
Please ask your queries. We are available 24/7
Tell us about your database architecture, application nodes, replication, networking, security requirements, and availability constraints. Our migration engineers will review the environment, identify platform-specific risks, and build a cutover plan around your actual workload.
