Legal / Service Assurance
Joy Services is committed to maintaining service continuity, infrastructure reliability, and clear communication when any replacement-related event affects a customer environment. This Replacement Policy defines the operational and commercial framework under which infrastructure components, virtual resources, dedicated systems, software environments, and associated service elements may be replaced, re-provisioned, migrated, or restored.
The purpose of this policy is not only to explain when a replacement is possible, but also to define how replacement decisions are made, what conditions must exist before a replacement is approved, what limitations apply, and how Joy Services balances customer requests with platform stability, abuse prevention, technical feasibility, and live production risk.
Important Notice
Replacement actions are evaluated based on service type, root cause, infrastructure availability, operational risk, and whether the issue originates within Joy Services infrastructure, upstream dependencies, software behavior, customer-side configuration, or third-party components.
VPS
VPS replacement may be performed on demand only when a verified issue is caused by our side, our platform layer, our storage, our node, or our managed virtualization environment.
Dedicated Servers
Dedicated server replacement may be possible if the reported issue remains unresolved after reasonable diagnosis, remediation attempts, hardware validation, and platform-level checks by our operations team.
Policy Summary
Joy Services provides infrastructure and digital services that may include virtual machines, dedicated servers, cloud storage, network resources, software stacks, managed operating systems, backup services, and supporting orchestration layers. Because each service category behaves differently in production, replacement eligibility is not governed by a single standard for all products. Instead, each replacement event is reviewed according to service architecture, operational impact, and root-cause evidence.
A replacement may involve one or more actions, including hardware swap, server migration, storage relocation, virtual machine redeployment, instance re-creation, software package replacement, image replacement, backup-based restoration, equivalent service provisioning, or movement to another stable platform under the same or similar commercial scope.
Replacement is generally intended for situations where an active service is materially affected by a persistent issue that cannot be resolved efficiently through ordinary support, maintenance, patching, repair, tuning, or configuration correction. Joy Services reserves the right to choose the safest technically valid remedy, which may include repair, migration, partial service restoration, temporary failover, or full replacement depending on platform conditions.
We investigate the issue before approving replacement, to avoid unnecessary service disruption and to identify whether the problem is platform-side, vendor-side, or customer-side.
We choose the safest corrective path first. Repair, migration, restore, or patching may be used before full replacement where appropriate.
Where redundancy, backup, failover, or alternate node capacity exists, we aim to reduce downtime during replacement operations.
Some replacements depend on inventory, region availability, virtualization limits, software licensing rules, and operational windows.
Service Category
VPS replacement is handled differently from physical infrastructure because a virtual server may be affected by multiple layers including hypervisor behavior, host node contention, storage latency, orchestration logic, image-level corruption, internal network faults, or user-managed operating system issues. For this reason, a VPS will not be replaced simply because performance appears inconsistent or because the customer prefers a different node.
Joy Services may approve VPS replacement on demand only if the issue is verified from our side. This includes cases such as repeatable host instability, virtualization-layer faults, storage-level failures, control-plane errors, recurring platform packet loss within our environment, or internal resource behavior that materially affects the promised service operation. Where such conditions are confirmed, we may migrate the VPS to a different node, redeploy it from a known-good template, restore from backup where available, or provision an equivalent replacement instance.
VPS replacement may be denied where the issue is caused by customer software, malware, unsupported applications, abusive workloads, poor internal configuration, kernel misconfiguration, OS corruption caused by customer actions, unauthorized access, or application-layer problems not attributable to the Joy Services platform. In such cases, support may still assist with diagnostics depending on the service scope, but replacement is not guaranteed.
Service Category
Dedicated server replacement is more operationally sensitive because it may require hardware reallocation, physical intervention, re-racking, storage handling, network reassignment, or controlled service migration. As a result, replacement decisions are based on the persistence and severity of the issue, the findings of our hardware validation process, and whether practical remediation has already been attempted.
Joy Services may approve dedicated server replacement where a critical issue remains unresolved after diagnostics, remote troubleshooting, replacement of defective sub-components, software correction, and other commercially reasonable remediation steps. This may include recurring motherboard faults, unstable memory behavior, disk subsystem errors, controller failures, network port instability, or other infrastructure conditions that prevent the server from operating reliably within normal expectations.
Where dedicated server replacement is approved, Joy Services may provide an equivalent or reasonably comparable platform based on current inventory, technical compatibility, available location capacity, and service plan scope. Exact hardware matching is not always guaranteed, but we aim to preserve the commercial intent and functional capability of the affected service as closely as reasonably possible.
Scope of Replacement
Replacement events may apply to underlying hardware components, service software, operating environments, storage systems, internal networking paths, or orchestration frameworks. In some cases, the visible customer outcome may still be called a “replacement” even when the technical remediation is a migration, rebuild, restore, failover activation, or movement to alternate infrastructure. The exact operational method is selected by Joy Services based on what best protects customer continuity and infrastructure safety.
For hardware failures, Joy Services will review monitoring data, platform logs, diagnostic results, and vendor guidance. If the issue is confirmed as a hardware-level defect or failure, our operations team may replace the affected component or move the customer workload to another stable environment. In cases involving vendor warranty or datacenter stock procedures, timelines may vary depending on component availability and access windows.
For software failures, the first course of action may include patching, package replacement, rollback, service restart, version pinning, restoration from known-good state, or controlled migration to another stable build path. Where a software issue cannot be resolved in a timely or safe manner, Joy Services may replace the affected software environment with an equivalent working configuration or an alternative supported deployment path.
For network-related service impairment within our infrastructure, Joy Services may modify internal routing, switch the affected path, move the service to an alternative host or network domain, replace the physical port or optical module, or reassign the customer to another available infrastructure segment where necessary for stability. Such changes may be treated operationally as replacement actions even when the public-facing service remains the same.
Hardware
Includes disk failure, controller instability, memory fault, NIC issue, PSU event, motherboard instability, CPU-related fault conditions, or physical chassis problems.
Software
Includes corrupted service environment, critical software bug, image-level defect, control-plane issue, orchestration fault, or managed stack failure.
Platform / Network
Includes internal network path defects, virtual fabric issues, platform-side latency anomalies, packet delivery impairment, or persistent node instability.
Process
To ensure replacement requests are handled consistently and fairly, Joy Services follows a defined workflow. This process helps separate urgent infrastructure faults from configuration issues, planned upgrades, cosmetic preferences, temporary service anomalies, or non-platform causes.
The customer should submit a replacement-related request through the designated support channel with as much technical detail as possible, including service ID, hostname, affected IP, error behavior, timestamps, screenshots if relevant, and a description of observed impact.
Our support or infrastructure team reviews logs, monitoring, platform data, hardware signals, and service behavior to identify the root cause and determine whether replacement is justified.
Where appropriate, we may first attempt repair, patching, tuning, migration, component swap, restore, or software correction before proceeding with full replacement.
If the service still remains materially impaired and the issue is verified within our operational scope, Joy Services may approve a full or partial replacement action.
We provide status updates, expected next steps, operational impact notes, and any migration requirements the customer must complete.
After the replacement action, the service is validated for stability, and customers may be asked to confirm normal operation from their side.
Detailed Terms
Replacement approval depends on operational evidence. Joy Services may reject or delay a replacement request where the reported issue is intermittent and not reproducible, where no platform-side abnormality is identified, where the issue is caused by the customer’s own software stack or actions, where abuse or policy violations are involved, or where the requested replacement would introduce higher risk than the original impairment.
Replacement does not automatically include data restoration, application repair, third-party license recovery, custom configuration migration, or manual software reinstallation unless these are already part of the purchased managed scope. Customers remain responsible for their own application-level continuity, secrets, credentials, custom packages, and data integrity unless covered by an explicitly managed service arrangement or backup product.
Joy Services may also determine that an equivalent alternative is commercially and technically reasonable instead of an identical replacement. This is especially relevant where specific hardware generations, exact storage models, region-specific inventory, or legacy software versions are no longer available or no longer suitable for stable production use.
Planned upgrades, customer-requested specification changes, migrations for convenience, node preference requests, geographic preference changes, or service redesign requests are not treated as “replacement” under this policy unless Joy Services independently determines that a verified service-side fault makes such a change necessary.
Persistent hardware failure, verified platform-side VPS instability, repeatable storage fault, unresolved network-side impairment within our infrastructure, defective component behavior, or software failure that cannot be corrected in reasonable time.
Customer misconfiguration, unsupported workloads, malware, abuse events, OS corruption caused by customer actions, application bugs, request for a different node without verified service-side fault, or performance expectations outside the purchased scope.
Communication & Transparency
Joy Services will maintain reasonable communication throughout a confirmed replacement process. This may include acknowledgement of the issue, confirmation of ongoing technical review, notification of whether the issue appears to be hardware, software, or platform-related, updates regarding replacement approval status, expected next operational action, and notice when the replacement work is completed.
Estimated timelines communicated during an incident are only best-effort operational guidance and may change based on vendor response, datacenter handling, component availability, maintenance windows, access restrictions, dependency failures, data restoration requirements, or additional technical findings.
Backup & Recovery
Joy Services operates backup and disaster recovery controls for supported platform scenarios, but customers should not assume that every replacement event automatically restores every file, database, snapshot, custom application, or runtime state unless an active backup or managed recovery service exists for that environment.
Customers are strongly encouraged to maintain their own application-consistent backups, export procedures, off-platform copies where appropriate, and verified recovery plans. Where our managed backup systems are part of the purchased service, restoration may be used as part of the replacement pathway when technically appropriate.
Extended Detail
For cloud instances, a replacement may mean node migration, snapshot restoration, image rebuild, or full instance recreation. For dedicated servers, a replacement may mean component swap, full server reassignment, alternate chassis allocation, or rebuild on comparable infrastructure. For managed software environments, replacement may mean re-provisioning of the application stack, deployment of a corrected image, substitution of a damaged package set, or restoration of a previous stable configuration. For network-backed services, replacement may mean port reassignment, optics replacement, path change, service migration to another rack, or movement to alternate available fabric where needed for stable delivery.
In all such cases, the replacement methodology is decided by Joy Services according to platform safety, speed of restoration, compatibility, and operational practicality. Customers may express preferences, but those preferences are not binding where they conflict with infrastructure policy, abuse control, security obligations, maintenance safety, shared platform reliability, or datacenter operating rules.
Replacement may also require temporary suspension of service access, scheduled coordination, IP reallocation, storage sync time, DNS updates, route propagation intervals, software reinstall windows, or controlled handover procedures. Customers are responsible for cooperating with reasonable migration or validation actions when a replacement is approved.
Cloud VPS
Replacement on demand only when the verified issue is on our side. Reinstalls, node moves, or redeployment may be used instead of physical-style replacement.
Dedicated Server
Replacement can be approved if the issue remains unresolved after technical review, hardware checks, and remediation attempts.
Managed Platforms
Software stack re-provisioning, version replacement, or restored clean deployment may serve as the replacement mechanism.
Exclusions
This policy does not guarantee instant replacement, exact like-for-like hardware in all circumstances, zero downtime, uninterrupted application continuity, preservation of unbacked-up customer data, compensation beyond applicable contractual commitments, or replacement approval for issues not attributable to Joy Services infrastructure or managed service scope.
Joy Services also does not guarantee replacement where the service has been suspended for abuse, non-payment, policy violation, legal restriction, export control issue, customer refusal to cooperate with diagnostics, or where the affected service has reached end-of-life, unsupported configuration status, or unsupported operating conditions.
Nothing in this policy should be interpreted as an unconditional entitlement to new hardware, free upgrades, capacity enhancements, region transfers, premium stock assignment, or special migration rights outside the purchased service plan and our current operational capability.
Customer Acknowledgement
By using Joy Services infrastructure, the customer acknowledges that replacement decisions must be executed according to real operational conditions and that the provider may determine the most appropriate corrective action in its reasonable technical judgment. This includes the right to repair instead of replace, migrate instead of rebuild, restore instead of reinstall, or provide equivalent infrastructure where exact matching is not practical.
Customers further acknowledge that replacement actions may require configuration cooperation, service validation, maintenance acceptance, and backup responsibility on their side. The goal of this policy is to support continuity and fairness while protecting all customers on shared or interconnected infrastructure.
Final Policy Note
Joy Services may review, refine, or update this Replacement Policy periodically to reflect infrastructure evolution, improved operational procedures, vendor constraints, product changes, service portfolio expansion, legal requirements, or updated customer support standards. The latest published version of the policy will govern future replacement requests unless a separate written agreement provides otherwise.
For replacement-related questions, customers should contact the official Joy Services support channel with the relevant service identifier and a complete description of the issue. Our goal is to handle each valid case carefully, transparently, and with a practical focus on restoring stable service as efficiently as possible.
Need more clarity?
Whether you're deploying infrastructure, scaling workloads, or optimizing network performance, our team is available to assist with architecture decisions, deployment guidance, and service clarification across all Joy Services offerings.
Availability
Engineering assistance available around the clock for infrastructure and network issues.
Response
Priority response times based on service level and deployment type.
Infrastructure
Distributed presence across major IX and data centers for reliability.
Network
Direct peering, IX connectivity, and optimized routing paths.