Conceptual scenario
Keep compute and storage in your office, lab or colocation rack. Fibmesh supplies the connections between that infrastructure, the people who use it and the outside world.
Request access ↗A worked planning example, not a customer case study or a released installation procedure.
One workload, a different home
A business wants to move a predictable application from a cloud VM to its own colocated server. Customers still need the application; staff still need private administration. Its database, scheduled jobs and partner integrations need explicit connections during the move.
One device
Your workload, on your hardware
Illustrative deployment. Workload migration and availability remain your operating responsibility.
Choose the new host, then account for every connection the workload uses.
The linked billing and ERP deployments are historical customer evidence. They are separate from this conceptual migration and do not establish its result, savings or platform support.
See billing and ERP deployments on existing servers →Private operators, public clients
Moving to your hardware does not require exposing administration or every service on the host. Choose private reachability, application publishing and public address delivery separately.
Staff / Private administration
Give approved working devices the intended private resource grant. Keep server administration, databases and private file access within their approved scope.
Retain the operating system and application accounts. A network grant does not replace administrative permissions or application authentication.
Explore Networks →Customers / Selected application
Use Publish for a supported HTTP application. Choose Public IPs when clients need an IP address and service port, with explicit incoming firewall rules and a verified return path.
Keep application login, API credentials and service permissions in place. Public reachability is an exposure decision; it does not make the service safe by itself.
Explore Public IPs →If the requirement grows
Routed Subnets is a separately arranged, invitation-led managed service with assisted setup. The current app does not provide self-service prefix provisioning. Agree the supported router, delivery and downstream firewall responsibilities before assigning addresses to VMs or services.
IPv4 and IPv6 are separate allocations; IPv6 prefixes range from /48 through /64. Confirm inventory, location and quoted service terms for the deployment.
Explore Routed Subnets →Confirm supported host and gateway combinations with assisted setup. Fibmesh Edge hardware remains a development/pilot deployment option. Review public address delivery and current availability before selecting the connection.
A practical migration
The application owner controls the migration. Use the connectivity plan to keep testing and recovery possible while the workload changes location.
Record callers, databases, scheduled jobs, external allowlists and service names. Identify which connections stay private, who owns each dependency and how to restore the existing service.
Confirm the supported endpoint or gateway, address family, public destination and any fixed outgoing source. Check the actual service listener, firewall rules and reply path. Agree any partner allowlist change separately.
Migrate data and credentials using the application’s own procedures. Test real client workflows, private administration, upload capacity and recovery. Verify that an unapproved administrative connection is denied; test IPv4 and IPv6 separately where applicable.
Update DNS and partner references within an agreed change and rollback window. Reconcile data before accepting new writes and retire the old service only after verification. The old cloud provider’s IP does not automatically become a Fibmesh address; seamless cutover is not promised.
What you still operate
The connection is one part of running the service. Assign these responsibilities before the workload leaves the cloud VM.
Fibmesh does not migrate data or turn one server into a highly available cluster. Floating public-subnet orchestration and automatic failover remain separate planned capabilities; this connection does not supply them.
For a hybrid period, connect supported hosts across providers through Networks and keep the application’s data and recovery procedures explicit.
Plan a hybrid environment →Start with a real workload
Bring the application’s current location, intended host, client service, private administration path and operating owner. Include the address family, dependencies and rollback requirement.
Use the cloud infrastructure plan for the wider deployment context. Share the intended deployment with Fibmesh to confirm availability and next steps.
Discuss your deployment →