todoencloud TODO EN CLOUD SL sells hosted capacity that still depends on racks, transit and repair windows

Summary

• TodoEnCloud is an operating Madrid cloud and managed-services company, not merely a dormant corporate or network record. It says it has run a public cloud since 2011; Tessi recorded acquiring the business in 2018; and current registry, certification, website and routing evidence all point to continuing activity.
• The company's Spanish public cloud is presented as three zones in three Madrid-area data centres connected by a dark-fibre ring. A November 2025 ENS certificate identifies the sites as Interxion at Calle Albasanz 71, DATA4 at Avenida de la Industria 15 in Alcobendas, and IPCore at Calle Marzo 16. Those are independent facility operators; TodoEnCloud appears to own or control the service equipment and network layer rather than the buildings, substations or generators.
• AS201346 originated four IPv4 /24 routes covering 1,024 addresses on July 12, 2026. RIPE's collectors saw three adjacent upstream networks, associated with Cogent, Lumen and NEAR IP, and the tested route had a valid RPKI authorization. This is substantial operating evidence, though the absence of visible IPv6 and of a PeeringDB record leaves gaps in the public interconnection picture.
• Three facilities are useful only when a customer's compute, storage, network, identity, management and backup components are deliberately placed across them. TodoEnCloud does not publish installed server counts, usable CPU or storage capacity, per-site headroom, oversubscription, recovery performance, incident history or a standard service-level schedule. Facility capability should therefore not be read as proof that every rented resource survives a site loss.
• Overall operating evidence is Strong, while public recovery evidence is Medium. A buyer can verify the legal company, parent, sites, certifications, address space and active routing. A buyer still needs a workload-specific architecture, power and fibre boundaries, recovery-point and recovery-time commitments, maintenance rules, support escalation, spare-hardware policy and a timed exit test before treating the cloud as portable or site-fault tolerant.

The cloud is concentrated in three specific Madrid buildings

TodoEnCloud's proposition is unusually useful for infrastructure analysis because it names the physical layer beneath its cloud. The company's public-cloud page says the service is distributed across three Spanish data centres, linked by a high-speed, low-latency fibre ring and presented to customers as three zones within one availability zone. Its data-centre page names Digital Realty, DATA4 and IPCore. Most decisively, the company's ENS certificate, issued in November 2025, identifies Interxion at Calle Albasanz 71, DATA4 Group at Avenida de la Industria 15 in Alcobendas, and IPCore Datacenter at Calle Marzo 16 in Madrid.

Those locations make the claim more than a diagram. Digital Realty lists Calle Albasanz 71 as its MAD1 facility, an 8,280-square-metre site in a four-facility Madrid portfolio. DATA4's Madrid campus page places its MAD01 site at the same Alcobendas address recorded on TodoEnCloud's certificate and describes a campus with substantial electrical reserves. IPCore's own facility description places a 1,200-square-metre carrier-neutral building at Calle Marzo 16 with redundant power and cooling, multiple fibre entrances and round-the-clock remote hands.

The physical pattern is therefore a Madrid metro cloud rather than a national spread across distant Spanish regions. Albasanz and Calle Marzo are in Madrid city; DATA4 is in Alcobendas, north of the centre. Separation within a metro can protect against a rack fire, a building outage, a local switch failure or work on one utility connection. It does less against a regional communications disruption, a broad power-system emergency, a software fault deployed everywhere, a common supplier problem or an operational mistake propagated by one team.

This distinction is not a criticism of metro design. Low latency between sites can make synchronous storage and clustered services practical, while a distant region would introduce delay and cost. It is a statement about the failure being insured. A fibre-linked Madrid cluster can be excellent for surviving one room or building failure. It should not be represented as equivalent to an independently staffed recovery region hundreds of kilometres away unless a customer has actually contracted and tested such a region.

TodoEnCloud itself uses an unusual formulation: three zones forming one availability zone. Cloud terminology is not standardized across providers, so the words alone do not settle the engineering. A customer needs the actual placement rules. If three virtual machines bearing three zone labels can still share a storage array, management cluster, firewall pair or backup catalogue, the labels overstate isolation. If the scheduler pins each copy to separate buildings with independent storage and network exits, the same labels may conceal a robust design. Architecture, not vocabulary, decides the outcome.

TodoEnCloud operates the service layer, not the whole physical estate

The corporate identity is clear. The website's privacy notice identifies TODOENCLOUD S.L. in Madrid and gives the same telephone number found in company directories. Commercial records place its formation in 2011. Tessi's 2019 annual report records the 2018 acquisition of Todo en Cloud as part of the French group's expansion into cloud architecture and data-centre services. The TodoEnCloud site now says its services form part of Tessi's Innovation & Trust digital factory.

That parentage matters in two directions. It provides a larger corporate context than the headcount of the Spanish subsidiary alone would suggest, and Tessi's original acquisition announcement said the deal would connect TodoEnCloud's Spanish capability with hosting platforms in France. But parent ownership does not prove that French capacity is a live failover destination for Spanish customers. Unless a contract, replication design and recovery test name a French site, the parent network is a strategic option rather than commissioned redundancy.

Ownership language on the company website needs similar care. TodoEnCloud describes "own infrastructure in Spain" and sometimes refers to "our" data centres. Yet the identified buildings are operated by Digital Realty, DATA4 and IPCore. The more precise reading is that TodoEnCloud owns, leases or controls servers, storage, network devices and software deployed in third-party colocation facilities, and buys power, space, physical security and site services under agreements with those operators. It may also lease fibre while lighting that fibre with its own optical equipment.

This layered ownership is normal. Few regional clouds need to own a substation, concrete shell and diesel tanks to provide a serious service. The consequence is that responsibility crosses contracts. Digital Realty, DATA4 or IPCore responds to a building alarm and maintains facility plant. A carrier or fibre provider repairs an external route. TodoEnCloud operates the customer platform, network policy and perhaps the lit optical layer. Hardware vendors supply servers, disks, network cards and replacement components. Tessi ultimately controls the subsidiary.

The customer owns the application, data model, credentials and whatever recovery design it purchased.

During a routine month, those boundaries are nearly invisible. During an incident, they determine who can enter the room, who has a spare part, who authorizes a fibre repair, who communicates with the customer and whether a service-level credit is owed. A provider can be accountable to the customer without directly controlling every restoration step. The important question is whether its contracts, monitoring and escalation rights are strong enough to manage those external dependencies under pressure.

The certificates prove a defined operating scope, not unlimited resilience

TodoEnCloud provides unusually concrete certification evidence. Its current ISO 27001 certificate covers the information-management systems supporting public and private IaaS at the Madrid head office and two data-centre addresses: Albasanz 71 and Avenida de la Industria 15. It is valid from July 2024 to June 2027. A separate ISO 27701 certificate covers the privacy information-management system for the same activity and two sites through September 2027.

The later ENS certificate is broader. It records all three named data centres and says the systems supporting public and private IaaS were audited against Spain's National Security Scheme at the Medium category. That provides a dated bridge between the company's three-site marketing and an external audit scope. It also resolves an apparent inconsistency on the company's security page, which still says ISO 27001 covers two data centres. The most plausible explanation is timing: the ISO documents list two sites, while the later ENS audit adds IPCore.

Certification is valuable because it establishes governance, a defined scope, an auditor and a validity period. It does not reveal capacity or make every workload highly available. ISO 27001 concerns an information-security management system. ISO 27701 extends privacy management. ENS Medium imposes controls for systems serving relevant Spanish public-sector needs. None of those documents says how many compute nodes are live at each building, whether customer volumes are synchronously replicated, how long a failed host takes to replace, or how a particular database behaved in the last outage.

Facility certifications must be separated from provider certifications as well. TodoEnCloud's data-centre page makes broad claims about Tier III+ or Tier IV facilities, N+1 components, independent substations, batteries and generators, and availability between 99.95 and 99.999 per cent. These appear to summarize site capabilities across the chosen operators. They are not a published TodoEnCloud service-level agreement, and the range itself spans very different downtime allowances. In a 365-day year, 99.95 per cent permits about 4 hours 23 minutes unavailable; 99.999 per cent permits about 5 minutes 15 seconds.

The customer contract must identify which figure, measurement point and exclusions apply.

A certification can also exclude a dependency that customers assume it covers. The ISO certificates name two CPDs while the public cloud now describes three. A managed AWS or Azure service sold by TodoEnCloud depends on those external platforms rather than solely on the certified Spanish cloud. An edge node at a factory or streetlight is physically outside the Madrid facilities. A customer's own on-premises cluster has its own power and security boundary. Scope should therefore be read service by service, not applied to the company logo as a universal property.

Installed capacity and usable capacity remain undisclosed

The largest public evidence gap is capacity. TodoEnCloud offers public cloud, private cloud, bare metal, Kubernetes, GPU instances, backup, disaster recovery, colocation and managed operations. It says customers can scale and pay for use. It does not publish the number or generation of compute hosts, total physical cores, memory, accelerator inventory, storage media, usable petabytes, normal utilization, rack power, reserved headroom or per-site distribution.

Without those figures, a buyer cannot distinguish installed from usable capacity. A rack may contain servers but lack enough committed power for all of them at maximum draw. A storage cluster may advertise raw drive capacity while parity, replication, snapshots and reserve consume a large share. A public-cloud pool may have spare aggregate CPU but not enough memory, GPU or local storage for a specific shape. A provider may be able to sell one more instance during normal operation but lack room to absorb all surviving workloads after a site failure.

The last distinction is the most important. Capacity that is usable on an ordinary day is not necessarily fault-tolerant capacity. Suppose three sites each run at 60 per cent of their safe customer load. Losing one would leave two sites trying to carry 90 per cent each before accounting for uneven workload shapes, storage locality or network limits. That might be recoverable. At 80 per cent normal occupancy, the two survivors would need to reach 120 per cent, which is impossible without shedding load or leaving some services down. The numbers here are examples, not estimates of TodoEnCloud's utilization.

They show why site count alone cannot establish recoverability.

Hardware inventory creates another gap. TodoEnCloud's private-cloud offer ranges from three-node deployments to large tailored environments, using customer hardware or provider-funded equipment. Its bare-metal offer promises dedicated physical control with cloud-style consumption. Those services cannot be restored by allocating any generic virtual machine. Recovery may require the same CPU family, memory size, network interface, accelerator, firmware or storage connection. A replacement node that exists in a warehouse is not yet cabled, configured and joined to the cluster.

Public pricing is sparse too. The provider emphasizes an operating-expense model and cost management, but does not expose a general rate card for compute, storage, egress, backup, remote hands or reserved capacity. That is understandable for tailored B2B architecture. It means hosting economics must be established in a proposal and contract. Buyers should ask how power-price changes, licence costs, replacement hardware, burst capacity, cross-site traffic, external transit and after-hours labour flow into the bill.

Smaller operators can sometimes provide more economical or attentive service than hyperscalers because they avoid a huge product catalogue and know each environment. They can also face lumpy procurement. One failed storage controller, end-of-life server line or delayed optics order can matter more when the fleet is compact. A credible capacity discussion therefore needs both a number and a replenishment plan: commissioned resources, safe sellable resources, resources held for failure, supplier lead times and substitutions already qualified.

The network is visibly active and more diverse than a single transit line

Network evidence is the strongest independent operating signal. RIPE assigned AS201346 to TODO EN CLOUD SL in November 2014. The company also holds the active IPv4 allocation 185.77.132.0 through 185.77.135.255. On July 12, 2026, RIPEstat's routing-status view showed four originated /24 prefixes, 1,024 announced IPv4 addresses, full visibility across its reporting IPv4 peers and no announced IPv6 space.

RIPE's observed-neighbours data showed three networks on the upstream side of AS201346: AS174, associated with Cogent; AS3356, associated with Lumen; and AS49600, NEAR IP. A representative /24 had a valid RPKI route authorization. CIDR Report likewise saw AS201346 originate the equivalent of a /22 through Cogent and Lumen paths. These observations substantiate active hosting and route diversity more persuasively than a product page alone.

They still need limits. A BGP collector can show that three upstream autonomous systems propagate TodoEnCloud routes. It cannot show that every site has physically separate entrances to all three, that each carrier can take the full traffic load, or that the circuits avoid a shared conduit, meet-me room or optical platform. Two carrier contracts can converge on one metro fibre route. Three routes can terminate on one edge chassis. A dark-fibre cut can isolate a site even while the public prefixes remain reachable from another.

The company's registered routing policy also appears older than the observed network. Its RIPE aut-num entity names AS35699 and AS201942 in import and export statements, while live observations show Cogent, Lumen and NEAR IP. Registry policy entities commonly lag operational arrangements, but the mismatch is a useful warning against treating administrative text as a live topology map. A customer requiring route assurance should obtain the current network diagram and test failover, not infer it from a decade-old entity.

There was no AS201346 entry returned by PeeringDB's public network query. That absence does not imply poor connectivity. PeeringDB is a voluntary operational directory, and a transit-led network can function without a listing. It does remove one common way to verify facility presence, exchange participation, traffic policy and public network contacts. The company's own pages advertise links to internet exchanges and multiple operators, but do not name exchange ports or capacities for AS201346.

The absence of visible IPv6 is a more direct service question. Four live IPv4 routes support conventional hosting, but customers building modern public services may require native dual stack. Provider-level network address translation or a separate upstream can sometimes supply IPv6 without an AS201346 route, yet that design should be explicit. A buyer should ask whether IPv6 is available to virtual machines and bare-metal servers, how addresses are routed during site failover, and whether DDoS protection treats both protocol families equally.

A fibre ring reduces some failures and creates its own repair problem

TodoEnCloud says its sites are interconnected through a redundant dark-fibre ring lit by the company. That is a plausible foundation for a metro cloud. Dark fibre gives the operator control of optical equipment and capacity rather than forcing every storage replication or east-west flow through metered internet transit. A ring can send traffic the other way after one span breaks, provided the topology, switching and remaining capacity work as intended.

The word "ring" is not the recovery test. The useful questions begin below it. Are the two paths in separate ducts and streets? Do they enter each building through different risers? Are the optical devices powered from independent feeds? Is path switching automatic? How long does fault detection and reconvergence take? Can the surviving side carry peak replication plus customer traffic? Does scheduled maintenance ever open one side of the ring, leaving a second cut able to partition the cloud?

There is also a distinction between owning light and owning glass. A provider may lease unlit fibre from a carrier and install its own transponders. That gives control over wavelength equipment while leaving civil repair with the fibre owner. A cable break can require street access, permits, splice crews and coordination among a facility, carrier and city. The repair clock is physical even when the service is called cloud.

Inter-site latency and loss affect storage behavior before they produce a total outage. Synchronous replication waits for remote acknowledgement and may slow when a link degrades. Asynchronous replication can continue locally but increases the amount of recent data at risk. A split-brain safeguard may deliberately stop one side rather than let two copies accept conflicting writes. From the customer's perspective, a cautious storage halt is still downtime, but it may be the correct choice to protect consistency.

TodoEnCloud advertises separate IP transit, DDoS and VPN services. That can simplify responsibility because one provider can manage both compute and connectivity. It can also concentrate failure if the same edge, support team, account state or network automation controls all of them. A resilient design should identify an out-of-band access path and a communications channel that remains usable when the production network or customer panel is unavailable.

Power resilience stops at the customer's actual rack path

The three facility operators describe serious power systems. Digital Realty's Madrid page lists N+1 cooling at MAD1. DATA4 describes a large Madrid campus with significant electrical capacity. IPCore advertises 2N UPS, a backup diesel generator and redundant cooling. TodoEnCloud summarizes its selected facilities as having independent substations, separate routes, UPS, batteries and generators.

Those features improve the starting point, but power must be traced from grid to workload. A building may have two utility feeds while a particular cage has one distribution path. A rack may receive A and B feeds while a server has one power supply. A dual-corded server may connect both cords to the same upstream panel by mistake. A generator can support critical load while cooling or noncritical areas follow a different priority. Maintenance may temporarily remove one redundant component.

Power density also limits usable hardware. GPU and bare-metal products can draw far more power per rack than older general-purpose servers. A facility with unused floor space may not have the deliverable kilowatts, cooling or bus capacity for another dense deployment. TodoEnCloud's new GPU pages advertise on-demand NVIDIA L4 and L40 resources, but do not state inventory, rack density or whether accelerator capacity exists at one or several sites. Customers should treat instantaneous scaling as a commercial promise bounded by the installed fleet.

Facility generators introduce fuel and restart dependencies. A brief grid event may be carried by batteries until generators stabilize. A longer event requires fuel stock, successful refuelling and continued cooling. After a complete power loss, compute, storage and network systems need an ordered restart. Storage must establish quorum, control services must return, and customer instances may compete for host capacity. A building's electrical restoration time is not the same as application recovery time.

The contractual measurement point matters. If the facility supplies power to TodoEnCloud's rack but a server power supply fails, the building may be within its service commitment while the customer is down. If the server runs but a storage volume is unavailable, a compute uptime measure says little. The buyer needs an end-to-end service definition for the resource purchased, with planned maintenance, emergency work and upstream exclusions stated clearly.

Storage, backup and disaster recovery are different products

TodoEnCloud's Spanish service catalogue includes backup and disaster recovery, which is a positive sign because it does not pretend that highly available compute makes backup unnecessary. Its cloud-services page says backups can be stored in different data centres and accessed through an S3-compatible interface. The same page presents disaster recovery as a service intended to restore critical data, systems and applications.

Customers still need to know whether those protections are included in the base resource or sold separately. A virtual machine replicated between hosts may survive one server failure while preserving accidental deletion or ransomware on every copy. A snapshot in the same storage cluster may help with rollback but fail with the cluster. A second copy in another building is stronger, though it can remain exposed to one set of credentials or one management plane. An immutable or offline copy protects against a different class of failure.

Recovery point objective and recovery time objective turn these products into measurable commitments. The recovery point determines how much recent data may be lost. The recovery time determines how long the business can wait. Neither should be inferred from the phrase "automatic backup" or from the number of facilities. A database replicated synchronously may target near-zero data loss but stop during a partition. A nightly backup may restore after a building loss but surrender a working day of transactions. Both designs can be rational for different workloads.

Restore testing is the evidence that matters. It should include credentials, encryption keys, network policy, domain dependencies, application order and the capacity required at the recovery site. A backup entity is not a recovered service. If the restoration depends on the same identity system, management console or documentation store that failed, the nominally separate copy can be inaccessible at the critical moment.

TodoEnCloud's public pages do not publish aggregate restore success, standard retention, cross-site replication intervals, immutable-copy options or tested recovery times. That does not mean the features are absent; its offer is tailored. It means the customer should insist that these details move from design conversation into a service schedule and acceptance test.

Support labour is part of capacity

The company's central commercial claim is attentive architecture and operations. Its site offers support options from 8x5 to 24x7, a 24-hour monitoring service, systems administration, migration help and named technical contacts. Customer testimonials emphasize responsiveness. For a regional provider, this human layer can be a genuine advantage over a ticket queue that knows nothing about the customer's application.

Human capacity is also finite. A disk replacement during a quiet afternoon is different from a site incident affecting many tenants. Monitoring may detect hundreds of alerts at once. Engineers must distinguish cause from consequence, coordinate with facility staff, protect data consistency, communicate status and prioritize recovery. A small team can be highly capable and still be saturated by correlated failures.

The public material does not state shift staffing, on-call depth, escalation response, incident severity definitions or remote-hands commitments. LinkedIn and business-data estimates suggest a modest Spanish company, though such counts are incomplete and should not be treated as an audited workforce figure. The relevant buyer question is not total employees; it is how many qualified people can act on this service at 03:00, how quickly a second person joins, and who has authority to call a site or carrier emergency.

Repair stock connects labour to hardware. Remote hands can reseat a cable or replace a known failed unit only when the part and procedure exist. Enterprise storage controllers, matched drives, proprietary transceivers and GPU components may have long lead times. Firmware compatibility can make a nominal replacement unusable. A provider selling managed private cloud should disclose which components are held on site, which are covered by vendor response, and what temporary degradation is acceptable while a cluster waits for full repair.

Maintenance windows create the subtler risk. Patching hypervisors, storage, routers and optical equipment is necessary, but each action consumes redundancy. A rolling host upgrade is low risk if workloads can move and spare capacity exists. It is higher risk when a site is already degraded or when a fibre path is under maintenance. Customers need notice rules, blackout periods and a statement of whether planned work counts toward availability.

Billing and account control can stop a healthy machine from being useful

Cloud failure is not always electrical. A billing dispute, expired payment method, quota error, licence problem or mistaken account suspension can make otherwise healthy capacity unavailable. TodoEnCloud emphasizes one point of contact and one invoice across managed services. That simplifies procurement, but it can also make the account relationship a common dependency across compute, connectivity, backup and support.

The website's general terms and conditions say additional product or service contracts may apply and take precedence. That is important: website terms are not the cloud SLA. A customer should review the signed order, service schedule, data-processing terms and acceptable-use rules for suspension triggers, notice, cure periods, credit calculation, data retention after termination and the treatment of a disputed invoice.

Quota is another commercial control. Pay-as-you-go language can imply unlimited expansion, but no regional cloud has infinite servers. An API request can fail because a tenant quota is low, a requested hardware shape is unavailable or capacity is reserved for someone else. Recovery architecture that assumes it can create hundreds of instances after the incident may fail precisely because everyone needs spare capacity at the same time. Reserved recovery capacity costs money because it cannot be sold twice.

A sound contract separates ordinary elasticity from disaster reserve. It says which resources are guaranteed, which are best effort, how quickly quota can be raised and whether a recovery site keeps matching capacity available. It also identifies the remedy. Service credits may compensate part of a monthly fee, but they rarely cover the customer's lost sales, regulatory exposure or recovery labour. The architecture must therefore prevent losses rather than rely on credits to reimburse them.

Spanish location is meaningful, but sovereignty is a stack

Data locality is central to TodoEnCloud's offer. The company says its public-cloud data centres are in Spain and that it does not transfer information outside Europe. The ENS certificate places the audited IaaS systems in three Madrid-area facilities. The Spanish legal entity and Tessi parent are identifiable. For buyers seeking a Spanish operating location, these are concrete advantages over a vague European region label.

Location does not answer every sovereignty question. Hardware vendors can be foreign. Support software, ticketing, telemetry, domain services and threat intelligence can involve other jurisdictions. A managed multicloud service may administer workloads on AWS, Azure or Google Cloud. Backup metadata can travel differently from payload data. A French parent may have governance or support access even when the servers remain in Madrid. None of these conditions automatically defeats sovereignty; each belongs in the data-flow map.

The company's security policy aligns its scope with ISO standards and Spain's National Security Scheme. Spain's Royal Decree 311/2022 requires security to be treated as an integral process and includes continuity, incident response, protection of stored and transmitted information, and auditing. ENS Medium certification is therefore more substantive than a self-declared locality slogan. It remains a category and scope assessment, not a customer-specific legal opinion.

Buyers should document where primary data, replicas, backups, logs and support records reside; who can access them; what encryption keys protect them; and which law governs each supplier. They should also distinguish data residency from operational autonomy. A workload stored in Madrid may still depend on a remote software repository, licence server or identity provider. A sovereign design can choose those dependencies consciously and provide alternatives where the business requires them.

The physical concentration in Madrid creates a tradeoff. It offers clear Spanish residency and low-latency multi-site design. It does not provide broad geographic dispersion. Customers facing a requirement for a distant copy may need another Spanish region, an on-premises target, Tessi capacity elsewhere in Europe or a second provider. That choice should be driven by threat model and legal need, not by the word sovereign alone.

Open software helps exit, but migration is still a physical transfer

TodoEnCloud says more than 90 per cent of its core is based on open-source software and presents API, Terraform and OpenTofu access. Its hybrid and multicloud service emphasizes documented methods, distributed workloads and reduced dependence on one supplier. These choices can improve portability by using familiar images, orchestration and entity interfaces rather than unique proprietary formats.

They do not make exit instantaneous. A customer must export virtual disks, databases, entity stores, snapshots, access policy, network definitions, secrets and monitoring history. Large data volumes are bounded by link speed and can take days or weeks. Applications may depend on provider-specific load balancers, backup catalogues, firewall behavior or managed operations. A source image can be open while the operational knowledge required to run it resides with TodoEnCloud engineers.

The EU Data Act makes this question especially timely. The European Commission's Data Act explanation says cloud and edge customers should be able to switch providers and that switching charges, including data-egress charges for the switching process, are to be removed from January 12, 2027. The regulation requires contractual information on procedures, formats, restrictions and estimated time, and expects infrastructure providers to facilitate functionally equivalent outcomes where possible.

Law can remove contractual obstacles; it cannot repeal bandwidth or application complexity. A clean exit still needs a current asset inventory, machine-readable export, destination capacity, secure key transfer, final synchronization, validation and a rollback decision. If hardware is customer-owned and colocated, the plan also needs physical release, packing, shipping and insurance. If TodoEnCloud owns the hardware, the customer needs images and data rather than the server itself.

The best portability test is a partial migration performed before termination. Export one representative workload, restore it elsewhere, measure transfer rate, identify undocumented dependencies and confirm that the old copy can be deleted after acceptance. This test also reveals whether a backup is usable outside the provider's own platform. An exit plan written only after service quality declines is already late.

The practical failure paths are correlated

TodoEnCloud's three-site architecture provides several ways to limit an incident, but customer impact depends on where correlation remains.

A rack failure can stop one host or storage shelf. Customers with instances on another rack may see no interruption; a single bare-metal tenant may wait for repair. A building power or cooling event can remove an entire zone. Customers distributed across independently powered sites can continue, while single-site resources cannot. A fibre cut may isolate storage or management traffic even when each building remains powered. Ring protection helps only if the alternate path has capacity and the optical layer reconverges.

An upstream failure can change reachability without harming servers. Three observed providers are encouraging, but a shared edge or route policy fault can affect all. A storage software bug can spread across sites if the same version and automation are used everywhere. A compromised administrator credential can bypass physical diversity. A faulty update can take down a common control plane. Geographic redundancy is weakest against failures deliberately replicated for consistency.

Hardware scarcity lengthens repair when a specialized node fails. Support saturation lengthens diagnosis during a broad event. Billing or identity mistakes can deny access across healthy facilities. A backup kept under the same credentials can be deleted with production. A migration can stall because destination capacity or egress time was never reserved. Each path crosses technical and contractual layers.

Who is affected also varies. A single virtual-machine customer may lose a website and its users. A managed private-cloud customer may lose an enterprise application, staff access and dependent suppliers. A public body using an ENS-scoped service may have reporting and continuity duties. TodoEnCloud faces repair cost, credits and reputation damage. Facility and carrier operators face their own service commitments. Tessi carries group-level commercial risk. The incident is one event, but the consequences are distributed across the chain.

What would make the resilience case complete

TodoEnCloud has already disclosed more verifiable infrastructure than many small cloud brands. A buyer can name the legal provider and parent, visit three facility addresses, inspect current certificates, observe routed address space and identify multiple live upstream networks. Those facts justify a Strong operating-evidence assessment.

The remaining work is customer-specific. Before treating a deployment as site resilient, the buyer should obtain a component map showing where compute, storage, control, identity, firewall, backup, monitoring and support systems run. The map should identify facility operator, power path, carrier path and fibre entry at each site without exposing sensitive security detail. It should state which elements are active-active, active-passive or single-site.

Capacity evidence should reconcile installed, sellable and recovery resources. It should show per-site headroom for the contracted shapes, storage reserve after replication, network capacity after a span or carrier failure, and lead times for replacement hardware. The provider need not publish fleet economics to the world, but the customer relying on recovery needs a defensible allocation.

The service schedule should define availability at the purchased-resource level, not merely cite facility tiers. It should specify measurement, maintenance, exclusions, support response, restoration priority, service credits, data retention and account-suspension safeguards. Backup terms should state location, immutability, retention, encryption ownership, recovery point and recovery time. The exit section should list formats, interfaces, egress capacity, assistance and deletion evidence.

Finally, the parties should test. Simulate loss of a host, one storage path, one transit provider and one data-centre link. Restore a workload from the separate backup. Reach support through the secondary channel. Export a representative service to another environment. Record the time and the manual steps. A successful test is better evidence than another availability adjective.

TodoEnCloud's appeal is that it offers a visible Spanish alternative to an impersonal global cloud, with people close to the architecture and three real Madrid facilities beneath it. That closeness can be valuable. It also makes the underlying bargain easier to see: customers are buying not weightless computing, but a managed claim on racks, power, fibre, inventory and skilled attention. The service is resilient when those claims are separated, reserved and rehearsed.

Until the customer-specific design proves that, the three-site platform is credible capacity with recovery options, not an automatic guarantee that every workload will survive every failure.