Sales and Scope Discussion
Contact Us
Use this form for product fit, deployment scope, DB Systems capability, packaging discussions, or POC License requests.
Existing customers should include organization context and portal access details when relevant.
Pre-Sales FAQ
Enterprise Scoping Questions
Does Yorigu require agents on source workloads?
No. Yorigu is designed to run Disaster Recovery and Migration workflows without installing persistent agents on source workloads. Source access is handled through administrative protocols already present in enterprise environments, such as SSH for Linux sources and WinRM for Windows sources, together with target platform APIs.
Which workloads does Yorigu cover?
Yorigu covers Physical Servers, Virtual Machines, and DB Systems as first-class workload types. The same product family can protect or move Machine and database workloads across Cloud, On-Premises, and Virtualized Infrastructure. DB System Workloads adds database-aware orchestration for Oracle, Microsoft SQL Server, PostgreSQL, MySQL, and SAP HANA.
What if our source workload runs on a cloud or hypervisor not specifically listed?
Yorigu reads source workloads at the operating system level and does not depend on the cloud provider or hypervisor underneath. Source coverage can extend across major public cloud, private cloud, on-premises, and virtualization environments, subject to operating system support, network access, and deployment scope.
How does Yorigu handle databases differently than generic VM-based DR?
A VM-level snapshot is not always consistent at the database level. Yorigu database-aware workflows track database consistency, validation, cutover readiness, and recovery state alongside Machine-level workflows for supported database engines. Recovery and migration decisions for mission-critical database workloads therefore do not rely only on the assumption that VM-level capture is database-safe.
Where does Yorigu run: in the vendor cloud or in our environment?
Yorigu runs inside the customer's controlled infrastructure, such as an OCI tenancy, a Proxmox VE environment, or a dedicated management host with access to the required source systems and target platform APIs. Customer workload data and workflow state remain within the customer environment.
How does Yorigu validate recovery or migration readiness?
Yorigu Disaster Recovery runs periodic validation workflows and keeps recovery readiness evidence visible over time. Teams can review whether protected workloads are recoverable before an actual failover event. Where database-aware workflows apply, validation evidence can include Machine, network, and database state.
What does AutoHealing do during failover?
AutoHealing helps Disaster Recovery workflows continue through unexpected source-side variations. During failover, Yorigu brings target workloads toward an operational, bootable state without requiring per-workload manual recovery work from the operations team. This reduces operator effort and improves the predictability of target activation.
Does Yorigu trigger failover automatically?
No. Failover is a business decision and remains with operators and business stakeholders. Yorigu does not initiate failover based on availability signals or thresholds. Once the decision is made, Yorigu executes the failover sequence as a coordinated workflow without requiring manual step-by-step intervention.
Are failover and failback handled by the same product?
Yes. Failback is part of the Yorigu Disaster Recovery lifecycle, not a separate product, separate license, or separate project. The same workflow covers the sequence from initial sync through failover, validation, and return to the original source environment.
How does Yorigu reduce DR infrastructure cost on OCI?
Yorigu Disaster Recovery for OCI supports a Cold Standby DR Target topology. Target VM compute does not need to run continuously; it is started only when validation or failover workflows require it. In normal standby state, cost is driven primarily by storage rather than always-on compute, with short-lived compute usage during scheduled validation tests. When failover is executed, target workloads are brought online as part of the orchestrated workflow.
How is Yorigu licensed?
Yorigu Disaster Recovery products are licensed on a subscription basis. Yorigu Migrate products are licensed on a project basis. License metrics include Machine count and DB System count; a single server hosting many small databases is counted as one DB System instead of being counted per database.
Can we evaluate Yorigu before purchasing?
Yes. POC License requests are scoped per engagement and typically validate Yorigu behavior on one or two representative workloads before broader rollout.
What makes Yorigu different from a generic migration script?
Yorigu is not a one-off script. It provides productized workflows, state tracking, validation evidence, source and target platform abstraction, and DB System-aware orchestration for repeatable Disaster Recovery and Migration operations.