Background
A construction company with roughly 100 users ran headquarters plus four remote offices on a network designed like a single LAN. The WAN links could not keep up.
File access was slow. The work-order application and anything that touched files directly needed a different path than hauling data over DSL.
Business Challenge
Remote sites sat on older DSL and network gear that was hard to maintain—much of it discontinued.
One operator walked us through her screen: about ten seconds on a single work-order action, and around fifty of those per day. Multiply that across remote staff and the link speed was the bottleneck, not the app.
The worst site was old DSL on very old hardware. It stayed up, but it was too slow for the volume of work going through it. Many of these offices are in very remote locations—limited circuit options made the problem harder to fix.
Solution
We swapped legacy routers for MikroTik CCR units at each site—supported gear with a full API for remote monitoring.
Site-to-site traffic runs over WireGuard. BGP handles routing between HQ and all four remote offices.
Most sites started on DSL. Two moved to high-speed circuits; one got a fixed wireless link—whatever was actually available at that address.
The work-order app stays on a terminal server we still maintain. Remote users get a session at HQ; file I/O stays on that box. When the legacy app needs an update, we patch it once on that server—remote users get the new version on their next login, with nothing to install at each office.
Implementation
We cut over one site at a time over about two weeks—four remote locations total. Each cutover followed the same steps: install the MikroTik CCR, bring the WireGuard tunnel up, rebuild routing and BGP, then move users. Circuit upgrades came later at several sites—we did not wait on faster internet to land before the new network was live.
With file traffic off the WAN, work-order response dropped to about one or two seconds. Operators could work at normal speed again; switching off DSL made a clear difference where high-speed or fixed wireless service replaced it.
Project Considerations
Each site had to be looked at closely for the options that were available. Many were remote sites.
One site at a time kept cutovers clean—new gear and tunnel first, circuit upgrade when the provider was ready at that address.
Environment Comparison
| Previous Environment | Current Environment |
|---|---|
| Work orders and file access over slow WAN links | Work-order app on terminal server; WireGuard carries session traffic only |
| ~10 seconds per work-order action (~50/day per operator) | ~1–2 seconds after circuits, routing, and terminal-server layout were fixed |
| Legacy routers—discontinued, no monitoring API | MikroTik CCR at each site with API-based remote monitoring |
| Most remote sites on DSL; static routing | BGP site-to-site; two sites on high-speed circuits, one on fixed wireless |
Key Outcomes
- ~10s down to ~1–2s — work-order entry after file traffic came off the WAN and links were upgraded
- Four sites in two weeks — MikroTik CCR, WireGuard, and BGP—one location at a time
- Terminal server kept — work-order app runs at HQ; one patch on the terminal server updates all four remote offices
- Remote offices under less stress — operators working at normal speed; faster internet where DSL was replaced
Long-Term Track Record
After go-live, operators at the remote offices were happy—they could work without fighting the network. Day-to-day stress dropped once the ten-second waits were gone and internet speeds improved where DSL had been swapped out.
Monitoring through the router API catches most issues before someone calls. New site or circuit change: CCR at the edge, WireGuard tunnel, BGP, terminal sessions for the apps that live at HQ.