We're taking over a production Java application from a SaaS provider whose service expires at the end of the month. The application is already running in our own environment, and it needs to remain operational indefinitely after the SaaS instance is shut down.
The problem is that we haven't completed a production database restore from backup, and our long-term backup and recovery process is still being established. Organizational restrictions currently allow deployments only to the test environment, not production. We also depend on another team for DevOps and infrastructure work. They're capable, but most of the systems they support use Python or Node, so some of the Java deployment and operational requirements are new to them.
At the moment, we can demonstrate that the application runs, but we haven't proven that we can recover it after a serious failure. Until we've successfully restored the database, cleaned or validated the recovered data as needed, and brought the application back to a functional state, I don't consider the recovery plan complete.
Is this kind of rushed transition common? It feels like we're building the production platform and its safety net at the same time, with a hard deadline imposed by the SaaS shutdown. For anyone who has inherited a system under similar conditions, what absolutely needs to be tested, documented, and signed off before the old environment disappears?
2 Answers
At a minimum, a backup must be restored successfully and the process documented. You also need enough retained backups to recover from scenarios such as ransomware, accidental deletion, or a bad application change. For a business-critical system, schedule a disaster-recovery exercise rather than treating a successful deployment as proof that recovery works.
Make the risks and missing controls explicit in writing to your manager and the people responsible for the transition. The deadline may be driven by cost savings, but the recovery risk is a management decision and shouldn’t exist only as an informal concern.
Clarify who is accountable for keeping the application operational in production and get that person involved immediately. If production deployment is blocked, the project needs an explicit risk acceptance or a change to the deadline—not an assumption that everything will work because the application currently starts.
Your team has already had to repair significant problems in the inherited Java system, and the infrastructure team is learning parts of the platform as they go. That makes a documented handover, tested deployment procedure, tested restore, monitoring, access review, and clear escalation contacts especially important before the SaaS service ends.
A transition being pushed through despite the deadline and unresolved recovery work is a sign that management needs to understand the exposure. The concern should be treated as a delivery and business-continuity risk, not just an engineering complaint.
I’m effectively responsible for the application, and I was brought in because the organization didn’t have someone with the necessary Java and cloud architecture experience. The system is working so far, but the lack of a proven recovery path is what worries me.