Application-Centric Orchestration
Application Plans raise the conversation from whether the VMs are protected to which business application can be recovered or cut over, in order, with proof.
An Application Plan groups Machines and DB Systems into application tiers, adds dependency order and customer approval gates, and records the evidence needed for recovery, migration, and operational review.
What it solves
Multi-tier applications fail or move as a system. Application Plans keep database, application, web/API, and integration steps visible so readiness is decided by business service, not by isolated machine status.
Sequencing
Plans can represent database, application, web/API, and integration order, with manual approval gates for database readiness, network/DNS changes, application validation, or operations checkpoints.
Health checks
TCP or HTTP reachability, database role or alignment signals, service reachability, and manual validation can be recorded between plan steps before the next tier proceeds.
Evidence
Execution order, gates, timestamps, approver identity, target versus achieved RTO, Yorigu-verified checks, and customer responsibility gates can support operational review and DORA or NIS2 evidence discussions without implying regulatory certification.
Yorigu Disaster Recovery
Define the business application and the recovery objective the plan needs to evidence.
Attach protected Machines and licensed DB Systems without turning the plan into a CMDB.
Arrange database, application, web/API, and integration tiers in the order recovery should follow.
Require named approvals for database readiness, network/DNS activation, application validation, or business acceptance.
Use the same plan shape for non-production test failover and real recovery execution.
Record what was verified by Yorigu, what was approved by the customer, and whether the application recovery target was achieved.
Yorigu Migrate
Define the application scope, cutover window, owners, and rollback expectations.
Keep machine or database movement prepared until the approved cutover point.
Confirm reachability, target readiness, database state, and plan approvals before production movement.
Run the final movement step under the application cutover plan.
Coordinate DB System cutover or readiness evidence before the application tier starts.
Start application services and record health checks or owner validation before traffic changes.
DNS, load balancer, firewall, connection string, and functional application validation remain explicit customer-owned gates.
Keep rollback assumptions visible until the customer accepts the new application state.
Summarize order, timing, approvals, checks, and responsibility boundaries for the cutover event.
Built on Machines and DB Systems
Application Plans use protected Machines and licensed DB Systems as building blocks. The plan records recovery and cutover order; it does not claim automatic dependency discovery or full configuration management.
Responsibility boundary
Yorigu can evidence the workflow, checks, and approvals it controls. Customer DNS, load balancer, firewall, connection strings, and functional application validation remain explicit gates in the plan.
Licensing
Application Plans is a separate licensed capability. DB Systems coverage does not automatically enable application-level orchestration; the license must grant application-plans explicitly.
Solutions
Use the Solutions page to compare when a workload decision is about a machine, a DB System, or the whole application plan.
View Application-Centric Use Cases