The enterprise resource planning (ERP) server may be exactly where it needs to be: on customer hardware, close to the people and systems that depend on it. A supported public IP delivery arrangement can make the ERP service remotely reachable while the server stays on customer hardware. Define the permitted service, reply route and recovery responsibility before making that address part of the application rollout.
For a software supplier, the awkward part can be repeating the connectivity work at each customer site. The local broadband arrangement varies. So does the way the customer can obtain a public address. Those differences can become part of an application rollout even when the software itself is unchanged.
What the historical Windows ERP deployment shows
In a historical Fibmesh deployment, an ERP provider ran its software on Windows servers at customer premises. Fibmesh was installed directly on those servers and supplied public addresses over the existing internet connections. The software remained on customer hardware; its public identity came from Fibmesh independently of the local internet service provider (ISP).
The application hosts used Public IPs with full-tunnel routing. This is a public-address deployment, and the routing scope concerned those hosts. It does not mean every device at each customer site used the same path.
Read the recorded customer-site ERP example →That account establishes a useful arrangement. It does not establish current native-client parity, a recovery-time guarantee or a standard configuration for every ERP package. The following questions are planning lessons for a new deployment, rather than additional claims about that historical customer.
Define the ERP protocol and public service boundary
Ask the ERP supplier what a remote client actually connects to. A browser application, a desktop client and a database connection can have very different requirements. Record the supported protocol, destination ports and application version before deciding how to deliver access.
Do not infer that the database needs to become publicly reachable because the ERP application does. The software may have a separate application service that clients are meant to use. Establish the supported boundary with the supplier and keep unrelated listeners outside it.
For a Windows host, review the rules that apply to the intended interface and network profile. Microsoft’s Windows Firewall overview describes filtering by application, address, protocol and port. Turning the firewall off to make the first connection succeed discards the distinction you are trying to establish.
Assess full-tunnel routing and outgoing integrations
A server does more than answer incoming users. It may contact licensing services, send reports, download updates or run a scheduled integration. These are assessment examples, not reported details of the customer deployment.
When the host’s internet traffic uses a different exit, those dependencies may see a different source address. Inventory them before changing the route. Ask whether an external system has an allowlist, a location restriction or an application policy that the new path must satisfy.
Test replies to incoming connections as well. Seeing an inbound packet at the server does not prove that its response takes a compatible route. A successful login and a completed application operation give better evidence than a network status indicator alone.
Assign application, host and public address owners
There may be a software supplier, a customer administrator, an internet provider and a connectivity operator involved. Give each a concrete responsibility.
Who maintains the ERP? Who patches Windows? Who can approve an inbound rule? Who owns the public-address arrangement, and who should receive notice before it changes? Put those answers in the deployment record while everyone is available.
Keep application accounts and permissions separate from network reachability. A connection to the ERP service should still require the correct application identity. NIST’s Zero Trust Architecture is useful background on why network location alone is insufficient evidence of trust.
Test remote ERP access and recovery
Choose a harmless operation that exercises the work users depend on. Verify it from the intended remote environment, then check that a caller without the required access is rejected. Confirm the application’s encryption, the host firewall and both required address families.
Also test routine recovery: a planned server restart, the service returning after maintenance and the supported procedure when connectivity is unavailable. Have a customer-authorized way to reach the machine locally if remote access fails. A new public address cannot replace power, a functioning internet connection or a recoverable application.
Keep the test results with the version and configuration assessed. That gives the next administrator something stronger than “it worked when it was installed.”
The value of this arrangement is a separation of decisions. The business can decide where its ERP belongs, while the public-address delivery is assessed on its own terms. Keeping the server on site is then an operating choice backed by a defined connection, rather than a reason to accept an undocumented exception.
