Summary
- Integrated Hosted Services, Inc. markets dedicated internet and cloud services, has Nebraska and Puerto Rico contact points, runs a customer billing portal, links to a support portal, and positions itself for E-Rate school and library connectivity work.
- The public network proof is real but narrow: ARIN records show AS401241 under Integrated Hosted Services, Inc.; RIPEstat showed AS401241 announced on 12 July 2026; and the only announced prefix visible in RIPEstat was 200.5.30.0/24.
- PeeringDB lists IHS at FiberX Data Center in Guaynabo and shows no public exchange LAN entries for the IHS network. RIPEstat showed one observed neighbour, AS6208, which RIPEstat and ARIN identify as FiberX.
- The honest evidence grade is Weak for resilience, even though the identity and route evidence are credible. The public record does not disclose IHS-owned rack count, usable power, hardware stock, transit diversity, restore testing, support response history or customer data-portability limits.
The company is visible, but the infrastructure proof is narrow
Integrated Hosted Services, Inc. is not a blank name in a routing table. The company has a public website at ihsamericas.com that sells dedicated internet service, describes cloud services, lists a Nebraska administrative office in Omaha and a Puerto Rico branch in Bayamon, and tells prospects that IHS delivers high-speed dedicated internet "built for your business." It publishes three dedicated-internet tiers: 250 Mbps for 20 to 50 employees, 500 Mbps for 50 to 100 employees, and 1 Gbps or higher for organizations above 100 employees. It also says IHS provides reliable dedicated internet and cloud services designed to maintain business continuity through redundant solutions.
That is enough to put IHS in the hosted-capacity and business-connectivity category. It is not enough to prove what a buyer most needs to know. A hosted service can fail in several ways that are not visible on a sales page: a rack can lose power, a customer can outgrow the assigned port, a single upstream can have a maintenance problem, a replacement router can sit out of stock, a support queue can miss a school-day outage, a billing suspension can cut service before a grant payment clears, or a customer can learn too late that moving data away from the provider requires manual work.
The public identity trail matters because it keeps the analysis grounded. ARIN's legacy REST record for AS401241 names the AS "IHS" and links it to Integrated Hosted Services, Inc. under organization handle IHS-101. ARIN's organization record for IHS-101 gives Integrated Hosted Services, Inc. an Omaha address at 8807 Q ST 102B and shows the organization registered in January 2020. ARIN's network record for NET-200-5-30-0-1 names OSN-IHS, covers 200.5.30.0 through 200.5.30.255, and associates the reassigned range with Integrated Hosted Services, Inc.
The timing is also useful. ARIN shows AS401241 registered on 8 July 2024 and the OSN-IHS 200.5.30.0/24 reassignment registered on 16 July 2024. RIPEstat's AS401241 overview showed the holder as "IHS - Integrated Hosted Services, Inc." and the AS as announced during the 12 July 2026 query window. RIPEstat's announced-prefixes view showed one announced prefix, 200.5.30.0/24, across the 28 June to 12 July 2026 window. That gives a current operating signal rather than only a historical registration.
The signal remains small. A /24 contains 256 IPv4 addresses before network, gateway, infrastructure, management, customer, reserve and address-policy constraints. It can support real services, especially for a small business internet or hosted-service provider, but it is not a large public cloud address estate. RIPEstat's routing-status view showed one IPv4 prefix, zero IPv6 prefixes, and one observed neighbour on 12 July 2026. The network exists. The public route view does not show a broad multi-carrier platform.
This distinction should shape every reading of IHS's public material. The company is visible enough to investigate as an infrastructure provider. It is not visible enough to assume that every service phrase on the website maps to owned servers, redundant data-centre capacity, multi-site failover or tested recovery. Public evidence supports a narrow conclusion: IHS has a live business connectivity and hosted-services surface, an autonomous system, one visible IPv4 route and a Puerto Rico facility signal through FiberX. Everything beyond that requires proof the public record does not yet provide.
The commercial offer is dedicated internet first, cloud second
The IHS home page leads with dedicated internet. It tells customers they can do more "with the right internet," markets high-speed dedicated internet for business, and sets out plans around employee counts and common use cases. The 250 Mbps tier is described for large file downloads, point-of-sale transactions and faster business communications. The 500 Mbps tier is framed around online collaboration, data backups and moderate file sharing. The 1 Gbps-plus tier is framed around high-growth businesses, significant online activity, frequent file sharing, hosting websites and running backup servers.
That language says something important about the service boundary. IHS appears to sell business connectivity and related hosted or cloud services rather than a hyperscale compute platform. The references to hosted websites and backup servers make cloud dependency relevant, but the headline transaction is bandwidth and continuity. A buyer is not just asking whether a virtual machine can be created. It is asking whether the provider can keep a site connected, keep backup traffic moving, keep local users productive, and respond during an outage that may also affect the provider's upstream or local facility.
The company's E-Rate page reinforces that sales posture. It describes the E-Rate program for schools and libraries, repeats the standard distinction between Category One connectivity to the outside internet and Category Two internal broadband connections, and lists eligible service examples such as Ethernet, leased lit fiber, wireless, cabling, caching, firewall services, racks, routers, switches, UPS or battery backup, access points, wireless controllers and supporting software. It also publishes FY2026 filing dates: 4 March 2026 for FCC Form 470 and 1 April 2026 for FCC Form 471.
USAC's public Eligible Services List page describes the same structure: Category One for data transmission services and internet access, and Category Two for internal connections, managed internal broadband services and basic maintenance of internal connections. That matters because IHS is not only selling pipes to ordinary businesses. It is also addressing institutions whose connectivity may be procurement-funded, calendar-bound and service-window-sensitive. A school network outage is not the same as an office losing a convenience service. It affects classrooms, library patrons, exams, attendance systems, security cameras, phone service, cloud learning platforms and administrative systems.
FRNHQ's public provider summary for Integrated Hosted Services INC, which states that it summarizes public USAC filings and is not affiliated with USAC, reports SPIN 143050393, roughly $6.75 million in committed E-Rate funding across 413 funded requests, 45 applicants, FY2020 through FY2026 activity, and Puerto Rico as the largest listed market. Those figures should be treated as a secondary filing summary rather than as a direct audit of IHS operations. They still point in the same direction as the IHS site: the company's practical exposure is heavily tied to Puerto Rico connectivity and school/library procurement.
The hosted-services angle becomes sharper when the IHS navigation is followed. The IHS services link redirects to an ISD Integrated Systems Development services page that lists internet access, internet transit, domain registration, web hosting, cloud dedicated services, consulting, software development, network and infrastructure services, hardware sales and support, and managed services. The page is broad and branded around ISD rather than cleanly around IHS, so it should not be treated as proof that IHS owns all of those capabilities itself. It is still relevant because the IHS site actively sends visitors there. The resulting buyer message is a bundle of internet access, hosted services, hardware, support and managed infrastructure.
That bundle has a different risk profile from a pure access circuit. When a provider sells only bandwidth, the key questions are port, path, upstream, service-level terms and repair. When it sells hosted and cloud-adjacent services as well, the questions expand to server inventory, storage, backup retention, account access, data export, support staff, billing state, application dependency and migration assistance. A "dedicated internet" product can be replaced by another carrier if the building has options and the customer owns its router.
A hosted website, backup server or cloud dedicated service may be harder to move because the customer's data and configuration sit inside the provider's operating environment.
That is why the article's title stresses racks, transit and repair windows. IHS can offer business value without being a giant cloud company. Small providers often serve local markets well because they are reachable, know the customer and can combine access, hardware and support. But the smaller the provider, the more important the physical dependencies become. Spare power, spare routers, spare access points, usable cabinets, technician availability, billing processes, upstream maintenance and customer exit paths become the real capacity.
The public route path runs through FiberX
The strongest live network evidence is AS401241. RIPEstat showed it as announced on 12 July 2026, and its prefix overview for 200.5.30.0/24 associated the prefix with AS401241 and holder "IHS - Integrated Hosted Services, Inc." RIPEstat's RPKI validation showed a valid route-origin state for AS401241 on 200.5.30.0/24, with a max length of /24. That is good operational hygiene. It reduces one kind of route-origin confusion and supports the conclusion that the route is intentionally authorized.
But route-origin hygiene is not route diversity. RIPEstat's ASN neighbours view showed one unique neighbour, AS6208, during the 12 July 2026 query. RIPEstat's AS6208 overview identifies AS6208 as "FIBERX - FiberX," and ARIN's legacy REST record for AS6208 also names FiberX. That makes FiberX the visible upstream dependency in the public BGP view.
PeeringDB gives the same shape from another angle. The PeeringDB network entry for ASN 401241 lists the network name IHS, long name Integrated Hosted Services, Inc., website ihsamericas.com, info type Cable/DSL/ISP, one facility, zero exchange connections, an open general policy, no public looking glass, no route server URL and no status dashboard. PeeringDB also lists five IPv4 and five IPv6 prefixes in the self-maintained network profile, while RIPEstat's live announced-prefixes view showed one IPv4 prefix and no IPv6 announcement at the query time. That mismatch is not unusual in operator-maintained profiles, but it is a caution. Public profile capacity should not be read as live routed capacity.
The PeeringDB netfac entry places IHS at FiberX Data Center in Guaynabo with local ASN 401241, created and updated on 16 July 2024. The PeeringDB netixlan view returned no exchange LAN entries for the IHS network. Again, that does not prove IHS has no private interconnection or customer circuits. It means the public interconnection profile does not show exchange fabric participation for IHS.
That is a meaningful downgrade for resilience. A small ISP or hosted-services provider can operate well with one upstream if the service is designed and priced accordingly. It can also be brittle if customers believe they are buying diverse internet paths. If AS6208 is the only publicly visible upstream, then the IHS route path depends on FiberX reachability, FiberX maintenance, FiberX local facility conditions, the IHS handoff into FiberX, the router or cross-connect between them, and the operational contact process when something breaks.
The public record does not disclose whether IHS has additional upstreams hidden from this route view, private transport, standby service, customer-specific carrier options, or failover arrangements. Those may exist. A customer should ask for them in writing rather than infer them from the existence of an AS number. The AS proves that IHS can originate a route. It does not prove multi-carrier service, geographically independent transit, active-active failover, spare router capacity, or a tested emergency route plan.
The RIPEstat routing-consistency view adds one more subtlety. It showed 200.5.30.0/24 as both in BGP and in whois-derived data, and it also listed 104.238.193.0/24 as in whois and IRR sources but not in BGP at the query time. RIPEstat's RPKI validation for 104.238.193.0/24 showed a valid origin authorization for AS401241. That can be a planned, reserved, inactive or otherwise unused route object. It should not be treated as live capacity until it appears in BGP and is documented in a service design.
The route conclusion is therefore balanced. IHS has credible public routing evidence, a valid ROA for its visible /24, and a facility/upstream story that coheres around FiberX in Puerto Rico. The public route evidence does not show the redundancy that a critical hosted-service buyer would need to see before treating IHS as a resilient cloud substitute.
Puerto Rico is the operating center of gravity
The assignment category is global, but the public evidence is not global in the way a multi-region cloud platform is global. IHS lists an Omaha administrative office and a Puerto Rico branch. The active route and facility signals point toward Puerto Rico. RIPEstat's MaxMind GeoLite view located 200.5.30.0/24 in Puerto Rico, with Humacao as the city in that geolocation feed. PeeringDB places IHS at FiberX Data Center in Guaynabo. FRNHQ's filing summary points to Puerto Rico as the dominant E-Rate market. IHS's own site gives a Bayamon postal address and a Puerto Rico phone number.
That location concentration is not a weakness by itself. A provider can be strongest precisely because it focuses on one geography and knows the access, procurement and support environment there. Puerto Rico is also an infrastructure market where local knowledge matters: geography, storms, power resilience, school procurement, last-mile reach, building access and carrier interconnection can all shape the real customer experience. A provider with a local presence can be valuable for customers that need a reachable counterpart rather than a distant generic helpdesk.
The risk comes when a locality-specific footprint is sold or understood as generalized cloud resilience. If a customer hears "cloud services" and assumes abstract capacity that floats across regions, the public evidence does not support that assumption. The visible network and facility evidence is concentrated around FiberX and Puerto Rico.
If a school, library or business wants resilience outside that geography, it should ask whether IHS can provide independent off-island backup, a second upstream, a second data-centre facility, public-cloud backup, a documented disaster-recovery target, or an exportable design that can be taken to another provider.
Data sovereignty and locality are also practical, not just legal. A Puerto Rico school or business may prefer local connectivity, local support and a local recovery partner. It may also need to know where backups sit, where hosted websites run, whether student or patron data crosses jurisdictions, and whether a provider can restore service if the local power or access environment is impaired. The public material does not disclose where IHS-hosted data resides, whether backups are local or off-island, whether customer data is portable in ordinary formats, or how fast a customer can move to another host during an emergency.
The FiberX facility context helps but does not remove those questions. FiberX's own colocation services page describes its Guaynabo Metro Office Park data center as a secure facility with redundancy, multicarrier and diverse fiber paths, hardened earthquake and hurricane posture, cabinets and cages, remote assistance, cloud connect, backup and disaster-recovery services, 2,000 square feet, capacity up to 60 cabinets, 24/7/365 access, cooling systems, UPS and generator details, 1,000 gallons of fuel storage and roughly five days of runtime without refueling. Those claims describe FiberX's facility and services. They do not tell us how much capacity IHS leases, which cabinet or port IHS uses, whether IHS customers inherit those features, or what commercial terms apply.
That distinction is the center of the operating analysis. A provider inside a capable facility may still run a single router, a small handoff, a limited cabinet or a customer-specific setup. It may also run more. PeeringDB tells us IHS has a facility presence at FiberX Data Center. It does not give rack count, power allocation, cross-connect inventory, spare equipment, customer workloads, or restore results. The public should not transfer the full facility operator's specifications onto IHS without proof of IHS's actual deployment.
Facility claims must stop at the operator boundary
FiberX is a real infrastructure context. The PeeringDB facility record for FiberX Data Center places it at Metro Office Park Street #1 Lot 6, B01, Guaynabo, Puerto Rico, lists FiberX as the facility operator, shows one exchange count, seventeen network count, one carrier count at the facility entry, and identifies available voltage services including 48 VDC and 480 VAC. PeeringDB's facility data also gives the CLLI PBVJPREYW00 and shows the facility record created in April 2024 and updated in December 2025.
For a customer, that is a useful facility signal. It suggests that IHS's public route and service story are not floating in abstraction. There is a named data center, a named upstream, and an interconnection environment in Puerto Rico. The facility page published by FiberX offers much more physical detail than IHS publishes: cooling, security, generator capacity, fuel, cabinet options, meet-me facilities and carrier-neutral language. That is all relevant to the failure paths a customer should test.
But the facility operator boundary is firm. FiberX's cabinet count is not IHS's cabinet count. FiberX's generator runtime is not automatically IHS's service-level commitment. FiberX's diverse fiber entry points are not automatically IHS's multi-carrier design. FiberX's remote assistance is not automatically IHS's repair response. FiberX's cloud connect or disaster-recovery services are not automatically part of an IHS contract. A customer that contracts with IHS needs to know which parts of FiberX's environment are included in the IHS service and which remain upstream facility attributes.
The same issue applies to the IHS E-Rate service mix. The company lists eligible equipment such as racks, routers, switches, UPS and access points. If IHS supplies or supports those items for schools and libraries, the operating surface extends beyond a data-center cabinet. It reaches campuses, wiring closets, access points, firewalls, battery backup, procurement schedules and repair dispatch. A campus network can fail even when the upstream data center is healthy. A rack UPS can fail locally. A school switch can run unsupported firmware. An access point can age out. A funding cycle can delay refresh.
These are not theoretical problems; they are the ordinary infrastructure economics behind managed broadband.
That is why "installed capacity" and "usable capacity" need to be separated. Installed capacity is hardware, ports, racks, routes and circuits that exist. Usable capacity is what can be sold, monitored, supported, powered, cooled and repaired under customer terms. IHS publicly shows a sales surface and a live route. It does not publish how much spare capacity is installed, how much of it is usable for new customers, how much is reserved for existing customers, what stock is available for replacement, or how maintenance is scheduled.
For hosted services, the same distinction applies to storage and compute. A provider may say it offers cloud dedicated services or hosted websites. The public buyer still needs to know whether those services run on IHS-owned hosts, FiberX-provided cloud services, another third-party platform, customer-owned hardware or a mix. It needs to know whether data is backed up, whether backups are immutable, whether restore tests are run, whether backup bandwidth is sufficient, and whether the customer can export data without a custom migration project.
The public evidence does not answer those questions. It does, however, identify where the questions should be directed: the IHS-FiberX boundary, the IHS customer-support boundary, and the customer-owned equipment boundary.
The failure path starts with transit concentration
The most visible technical failure path is transit concentration. If AS401241 is reached through AS6208 in the public route view, then any customer service that depends on AS401241's public reachability is exposed to the health of that relationship. A route leak, router failure, cross-connect outage, misconfiguration, upstream maintenance event, congestion point or RPKI error could affect reachability unless IHS has an alternative path not visible in the public data.
Valid RPKI helps with one narrow problem. It shows that 200.5.30.0/24 is authorized for AS401241. It does not prove that another upstream is available. It does not prove that the prefix is announced from multiple facilities. It does not prove that IHS has a tested procedure to shift traffic. It does not prove that customers can keep the same addresses if they migrate. It does not prove that a school, library or business can keep operating if the FiberX handoff is impaired.
The public PeeringDB profile also lacks a looking glass and status dashboard. Those absences are not fatal. Many small providers do not publish them. But they reduce public verifiability. A looking glass would let customers test route reachability. A status page would show incident discipline. A published maintenance page would help customers plan around school hours or business-critical windows. Public route policy would make it easier to see whether the PeeringDB prefix counts reflect planned capacity or stale profile data.
Transit concentration also affects support. If an outage occurs on the single visible upstream path, the customer may call IHS, IHS may need FiberX, FiberX may need a facility or upstream action, and the final repair may sit outside IHS's direct control. That can be acceptable if the escalation path is documented and tested. It is risky if customers believe IHS can fix every layer directly.
The practical customer questions are straightforward. Which upstreams carry the service? Is 200.5.30.0/24 announced through more than one path? Are customer services reachable if AS6208 has a maintenance event? Is there an off-island path for business-critical customers? Is there a documented emergency route change process? Who can authorize BGP changes after hours? How often are failover tests run? What happens to customer IP addresses if a customer leaves?
Without answers, the route evidence should be read as a real but narrow operating signal. It supports a Weak resilience grade because the public route view does not show the independent paths expected for critical hosted capacity.
Support and billing are part of the service boundary
IHS publishes a billing portal and routes its support link through support.ihsamericas.com toward a SherpaDesk-hosted helpdesk domain. The billing portal is a live customer-login surface. The support redirect is a live support-channel signal even though the destination did not expose a public helpdesk page during this review. These surfaces matter because a hosted-service provider's failure is often administrative before it is physical.
Billing state can affect continuity. If a school district relies on grant reimbursement, purchase orders, installment billing or delayed public payment, the provider's billing process has to tolerate procurement reality. A mistaken suspension, unresolved invoice, portal outage or account mismatch can become an availability problem. The public IHS portal confirms that customer account management exists. It does not disclose suspension policy, billing grace periods, dispute handling, grant-payment accommodation or emergency contacts.
Support state can affect repair. A circuit outage may be obvious; a hosted backup failure may be quiet until restore day. A failed school switch may look like an upstream problem to classroom users. A DNS or hosted-web issue may land in the wrong queue. If the provider sells internet, cloud, hardware and managed services, support triage has to identify which layer failed and who owns it. The public pages do not disclose escalation tiers, on-call coverage, mean time to respond, mean time to repair, spare equipment process, after-hours remote access, field dispatch or customer notification practice.
The IHS contact page says "We Love To Help" and invites visitors to ask anything anytime. That is friendly sales language, not operational evidence. The home page says IHS offers professional support and networking expertise. Again, useful but not enough. A buyer should ask for concrete support terms: hours, emergency channels, escalation path, response targets, replacement hardware process, maintenance notification policy and incident reporting. For E-Rate customers, it should also ask how support terms interact with school calendars, fiscal years and eligible-service contracts.
The support boundary is especially important for a provider whose public facility dependency appears to run through FiberX. If a physical port fails at FiberX Data Center, who opens the ticket? If remote hands are needed, who pays and who authorizes access? If a router needs replacement, where is the spare? If a campus access point fails, is that IHS support, school staff support or a third-party installer? If a billing portal account is locked while service is down, can the customer still reach an emergency line?
These details are not decorative. They determine whether hosted capacity survives a failure. A cloud promise may fail because nobody can authorize a replacement part. A dedicated internet promise may fail because a circuit ticket is stuck between entities. A school network may fail because the repair window collides with class hours. Public IHS material does not resolve those questions, so the article treats support and billing as unresolved dependencies rather than settled strengths.
E-Rate exposure makes calendar risk operational
IHS's E-Rate page is not a side note. It changes the infrastructure risk. E-Rate work is shaped by filing windows, competitive bidding, eligible service categories, documentation, reimbursement and school/library budgets. A provider serving that market has to deliver technically and administratively. A project can be harmed by a missed form, a delayed contract, a bad inventory, a support gap or a mismatch between eligible equipment and actual network need.
The IHS E-Rate page names FY2026 filing dates and describes eligible Category One and Category Two services. That suggests IHS wants to be involved before and during customer procurement, not only after a circuit is live. FRNHQ's summary of public USAC filings reports activity from FY2020 through FY2026 and a large Puerto Rico concentration. Official USAC quarterly school-and-library XLSX filing materials are also discoverable with Integrated Hosted Services INC appearing as a service provider name in disbursement-to-service-provider files.
Together, those sources support the conclusion that IHS has meaningful exposure to the schools-and-libraries connectivity market.
That market has real operating stakes. A school or library cannot treat connectivity as a simple optional cost. Internet access supports instruction, administration, public access, testing, digital textbooks, library services, security systems and communication. Category Two equipment affects the inside of the building: switches, access points, routers, cabling, UPS and related services. The failure path can therefore start in a classroom wiring closet as easily as in a data-center rack.
Calendar risk sits on top. The IHS page says Form 470 for FY2026 had a 4 March 2026 deadline and Form 471 closed on 1 April 2026. If a customer misses a filing window or delays an award, it may not be able to buy or refresh infrastructure on the desired schedule. If the provider cannot deliver equipment before a school year starts, the service gap is experienced as an operating failure even if the network design was sound. If a provider runs out of hardware stock during a refresh wave, schools may be left with old switches, overloaded wireless or fragile backup power.
The public IHS material does not publish inventory practices, school-year deployment capacity, field technician coverage, spare hardware levels or project backlog. That absence matters more in an E-Rate context than in a normal business broadband sale. A business can sometimes defer a migration. A school calendar is less forgiving. The provider's real capacity includes procurement execution, not only ports and prefixes.
The same logic applies to maintenance windows. A provider may have to coordinate outages around school hours, exams, library opening hours or local events. Public IHS pages do not show a maintenance calendar or customer-notice archive. A buyer should ask for planned maintenance windows, emergency maintenance policy, notice periods, and whether critical customers can request blackout periods. For a connectivity provider serving public-interest customers, maintenance discipline is part of capacity.
Hosted capacity also depends on exit paths
The public record gives IHS a credible hosted-services and connectivity profile. It does not disclose data-portability terms. That is a quiet but important risk. Customers often focus on getting service installed and forget to ask how they leave. The exit question becomes urgent when a provider fails, raises prices, loses an upstream, changes billing terms, suffers a support breakdown or cannot scale with the customer's needs.
For dedicated internet, exit terms include circuit cancellation, customer-owned equipment, IP portability, DNS handover, router configuration, local wiring and overlap with the new provider. If the customer uses IHS-assigned addresses from 200.5.30.0/24, it may need to renumber when leaving. If the customer has hosted websites or backup servers, it needs data exports, credentials, images, backup copies, DNS records and a cutover plan. If the customer uses managed devices, it needs configuration files, admin access, licensing information and inventory.
None of these questions are answered publicly. The company may provide them privately. The point is that a customer should not buy cloud or hosted service based only on access speed. A 1 Gbps link is useful, but if the customer's backup data is slow to export, the real recovery time may be measured in days. A business-continuity phrase is useful, but if the failover procedure is manual and undocumented, the continuity may depend on one technician's availability.
The Puerto Rico concentration makes exit planning even more important. If a local event affects power, roads, staff or a facility, a customer may need to restore service elsewhere. That does not mean all data should be off-island. It means the customer should know the locality choice and its consequences. Some customers may prefer local hosting for latency, support and jurisdiction. Others may require a second copy outside Puerto Rico. The public IHS material does not state the default.
There is also an ownership boundary around customer premises. If IHS supplies routers, switches, UPS systems, access points or hosted servers under an E-Rate or managed-services contract, who owns them at the end of the term? Who holds admin credentials? Who can update firmware? Who has configuration backups? Who can reinstall service after a failed device? Equipment ownership and credential control can determine whether a customer is portable.
The public grade cannot be stronger without those answers. A provider that publishes simple exit and portability terms can earn trust even with a small network. A provider that leaves portability private forces customers to negotiate it before signing. For IHS, the public buyer should insist on portability terms for hosted data, assigned IP addresses, DNS, configuration backups, equipment ownership and emergency migration assistance.
What would upgrade the evidence grade
The first upgrade would be a clear service boundary. IHS could state which services it provides directly, which run through FiberX, which run through ISD, which are customer-premises services, and which are third-party cloud or software services. That would not require disclosing sensitive customer information. It would simply tell buyers what IHS controls.
The second upgrade would be a network transparency statement. IHS could publish its upstream count, whether 200.5.30.0/24 is announced through more than one path, whether any IPv6 service is live, whether 104.238.193.0/24 is planned or reserved, whether customer services can fail over, and whether RPKI and route objects are maintained. A public looking glass, status page or maintenance notice archive would further improve confidence.
The third upgrade would be a facility-scope statement. Because PeeringDB places IHS at FiberX Data Center, customers should know whether IHS uses a cabinet, partial cabinet, virtual presence, customer-specific equipment, cross-connect, transport handoff or broader hosted platform there. It should state whether customer workloads are hosted in Guaynabo, whether backups are local or off-site, whether power is A/B, and whether remote hands are included.
The fourth upgrade would be recovery evidence. A provider can publish recovery practices without exposing customers: backup frequency, restore-test cadence, spare-router practice, hardware replacement windows, escalation path, support hours, incident-notice process and sample maintenance windows. For schools and libraries, it could also publish school-year deployment expectations and support blackout practices.
The fifth upgrade would be customer portability language. IHS could state how customers export hosted data, transfer DNS, retain or replace IP addresses, recover configurations and migrate equipment at the end of a term. That would make the hosted-services offer easier to trust because customers would know the cost of leaving.
None of those upgrades requires IHS to become a large provider. In fact, they are most useful for small and local providers. A small provider can compete on clarity, proximity and support. But clarity has to be specific. "Redundant solutions" is a promise; route diversity, spare equipment, backup tests and support escalation are proof.
The operating verdict
Integrated Hosted Services, Inc. has credible public identity and network evidence. Its website sells dedicated internet and cloud services. Its E-Rate material speaks to schools and libraries. ARIN ties AS401241 and the OSN-IHS 200.5.30.0/24 reassignment to Integrated Hosted Services, Inc. RIPEstat showed the AS announced and the /24 live on 12 July 2026. PeeringDB places IHS at FiberX Data Center in Guaynabo. FiberX's own facility material describes a hardened Puerto Rico colocation environment. FRNHQ's public filing summary suggests that IHS has a meaningful E-Rate business concentrated in Puerto Rico.
The same evidence imposes a ceiling. Public routing shows one visible IPv4 prefix, no IPv6 announcement at query time, and one observed neighbour. PeeringDB shows no exchange LAN entries for IHS and no status dashboard. IHS does not publish rack count, power allocation, cooling design, customer capacity, spare hardware stock, support response history, maintenance records, failover tests, backup terms or data-portability rules. FiberX's facility claims cannot be transferred wholesale to IHS without knowing what IHS actually uses and controls.
The result is a company that should be taken seriously but not over-credited. IHS looks like a real business-connectivity and hosted-services provider with Puerto Rico as the practical operating center of gravity. The public record does not yet prove resilient cloud capacity in the broader sense. For ordinary buyers, the due diligence is not abstract.
Ask where the service is hosted, which facility and upstreams carry it, what happens if FiberX or AS6208 has a problem, what hardware is spare, who answers after hours, what the billing grace process is, how school-year maintenance is handled, and how data and configurations move away if the customer leaves.
Until those answers are public, the best evidence grade is Weak for resilience and Medium for identity. Integrated Hosted Services, Inc. exists in the network record and appears to serve real customers. Its hosted capacity still has to be measured in racks, transit paths, repair windows and exit plans.

