Let's talk networking. And AI. And infrastructure. And everything. Register for Connect 2026
Megaport Connect
A first-of-its-kind virtual summit built to help network engineers and IT leaders upskill, share ideas, and connect around the future of cloud and hybrid networking
Go behind the scenes of a complex, real-world multi-cloud migration involving AWS, Azure, and GCP. Steve Mikulasik outlines the challenges faced in inter-cloud routing, DNS design, and IAM policy alignment.
He shares what broke, what worked, and how his team refined architecture post-migration to optimize performance, security, and operability.
Presented by: Steve Mikulasik, Manager, Global Network Engineering at Civeo.
Steve Mikulasik, Manager of Global Network Engineering at Civeo, shares Civeo’s cloud networking journey from a rapid company spin-out through multiple rounds of redesign. Civeo provides workforce accommodations in remote locations across Australia and Canada, primarily for oil and gas and mining customers. From a network perspective, those sites range from a few hundred users to several thousand and must support guest internet access, SCADA, back-end systems, cloud services, offices, radio towers, and other operational requirements.
The central story is not a clean greenfield cloud migration. Civeo had to build a new enterprise infrastructure while existing operations continued, then later unwind earlier design choices as business requirements, connectivity options, and cloud consumption patterns changed. The company moved from on-premises and colocation infrastructure into an infrastructure-as-a-service environment, then into Azure connectivity with Megaport, and eventually toward a network-as-a-service model built around Megaport Virtual Edge.
The case study is positioned around multi-cloud readiness, with the most substantive detail centered on the network architecture required to make that readiness practical: retiring MPLS, simplifying physical points of presence, preserving next-generation firewall controls, avoiding provider lock-in, and creating an edge fabric that can connect cloud providers, remote sites, and future acquisitions without redesigning the network each time.
Civeo operates in remote geographies where network access is not simply an office convenience. Sites must provide internet access to large user populations while also supporting facility operations and internal IT services. That creates a mixed environment with different traffic profiles:
The company’s physical footprint also matters. Remote locations often have constrained fiber routes, unusual carrier options, and performance characteristics that do not always align with what a map suggests. Certain “Goldilocks” locations, where routes, providers, and geography fit together well, can have an outsized impact on network performance even if they are not the obvious hub locations from a traditional enterprise network planning perspective.
This context shaped the migration strategy. Civeo needed a network that could support users and operations in difficult locations, integrate cloud services, and keep enough flexibility to absorb future changes without repeatedly rebuilding core connectivity.
Civeo was created in 2014 after being spun out from its parent company. The transition created a demanding combination of requirements: existing systems had to keep running, but Civeo also had to stand up new infrastructure for the new company. The target timeline was about six months.
The existing infrastructure was based on on-premises systems and colocation environments that Civeo could not simply take with it. That meant the team had to build new infrastructure while maintaining the old environment during the transition. The urgency pushed the company toward a large infrastructure-as-a-service provider that could deploy servers quickly and scale.
The migration succeeded, but the chosen provider proved poorly suited to Civeo’s enterprise networking needs. Civeo had three different MPLS providers to connect, and the timeline forced those circuits to land in three different colocation facilities. That fragmented starting point made integration much harder.
The provider’s guidance was limited. The practical answer was essentially to use GRE tunnels. GRE was a starting point, but it did not answer the broader enterprise design problem. Civeo had to build an overlay to connect into the provider’s environment, connect to the underlay in some places, and use strategic static routes to make the overall design work.
The result was a complex configuration, including significant work with Vyatta. It functioned, but it was not the kind of architecture the team wanted to keep extending. Civeo, the provider, and other customers were seeing the same mismatch: the platform could deploy infrastructure, but it did not provide the enterprise network model Civeo needed.
By 2018, Civeo decided it needed to move on from the initial IaaS platform. A major factor was available expertise. Internal resources and external partners were generally more experienced with Azure, which made Azure a practical destination for a faster migration.
At the same time, Civeo was already retiring its MPLS networks. Mikulasik estimated that by this point the retirement was well over 50 percent complete, and by the end of that year most of the MPLS estate had been shut down and replaced with direct internet access.
This mattered because many earlier network decisions had been shaped by MPLS constraints. Once those networks were going away, the old accommodations no longer made sense. The team had an opportunity to simplify, but it also had to avoid building another architecture that would become a constraint later.
Civeo chose one North American point of presence and used Megaport to connect into Azure. The decision was not only about the immediate Azure migration. Mikulasik expected that multi-cloud connectivity would likely become necessary, and he wanted a design that could support that from the beginning. Civeo had made acquisitions in the past, so the network needed to be ready for future business changes and inherited environments.
The Azure migration and related connectivity work happened at a time when cloud networking documentation and partner experience were still uneven. Documentation changed frequently and could be out of date. Network-specific training was often embedded inside broader cloud training aimed at servers and services rather than written for network engineers designing enterprise connectivity.
ExpressRoute was a particular example. Some partners had only limited experience with it, sometimes in narrow use cases such as Office 365 connectivity. Civeo had to learn quickly and solve design questions that were not always answered cleanly in vendor documentation.
The lesson is that cloud migration can require network teams to build provider-specific expertise while the project is already moving. Familiar enterprise skills still matter, but the operational details shift:
The project ultimately went well, but the experience reinforced the need to revisit earlier decisions once the immediate migration pressure had passed.
By 2023, all of Civeo’s MPLS networks had been retired. That changed the design baseline. Several elements that once existed to accommodate MPLS providers were still present, but the original reason for them no longer applied.
The Australian network-as-a-service platform Civeo had been using, Telstra Programmable Network, had also become a concern. It had worked well for Civeo and operated in a way similar to how Megaport Virtual Edge works today: a virtual firewall could be stood up and connected into cloud providers or other companies. Over time, however, issues with the product made it appear likely that the service would end.
The review also sharpened Civeo’s view of physical points of presence. Remote sites still benefited from being near the right network hubs, especially in geographies with limited fiber paths. Low Earth orbit providers such as Starlink had become important in remote areas, and proximity to ground station connectivity could meaningfully affect performance. Civeo had seen Starlink deliver lower latency than some fiber providers because of the more direct path through space.
Physical PoPs still mattered for performance, but owning and managing them was slow and operationally heavy. Enterprise procurement and physical infrastructure management added friction without enough direct business value. Civeo wanted to preserve the performance benefits of good network placement while reducing the burden of maintaining physical PoPs.
Network as a service fit Civeo because the company needed a reusable connectivity fabric. The team did not want to reinvent the architecture every time Civeo added a cloud, added a colocation site, or completed an acquisition. The goal was to plug new networks into a consistent model.
Vendor lock-in was another important concern. Mature cloud users can become tightly bound to specific cloud architectures as they consume more provider-native services. Civeo wanted to pull some networking complexity out of individual clouds and back into an edge layer the company could control. That would make clouds more interchangeable where possible and preserve the option to move or expand later.
The desired model had several characteristics:
Megaport Virtual Edge became the platform Civeo used for this strategy. The ability to spin up links quickly, described as a real 60-second capability, changed how the team thought about network deployment. Work that previously required heavy planning and procurement became much easier to execute.
Civeo’s final reference architecture used Megaport Virtual Edge as the edge fabric. The design included two Azure ExpressRoute on-ramps connected through Megaport. In each key metro, Civeo deployed two firewalls in different data centers. Those firewalls were connected with a VXC mesh and tied back into the ExpressRoute connectivity.
Remote sites connected using VPN tunnels. The design gave Civeo a relatively simple and repeatable pattern:
The architecture was intended to avoid repeated rebuilds. Instead of designing a separate connectivity and security approach for each cloud or location, Civeo could use the edge fabric as the common integration point. So far, Mikulasik described the design as simple, straightforward, and effective for Civeo’s needs.
Deploying Megaport Virtual Edge itself was described as straightforward. The more difficult part was the firewall vendor architecture and the operational implications of running virtual firewalls in this kind of distributed environment.
Standing up a single firewall is relatively simple. High availability is where caution is required. Some vendor HA protocols may be old or not well suited for cloud-like or distributed virtual deployments. Documentation may not be current enough or broad enough to cover every scenario an enterprise will encounter.
Mikulasik’s recommendation was to avoid vendor HA protocols where possible and design around them. That does not mean avoiding resilience; it means being careful about relying on HA mechanisms that may have been designed for different deployment assumptions.
The CPU impact of next-generation firewall features also needs attention. Virtual firewall products run on CPU platforms, and advanced security features can materially affect performance. Testing should account for the actual feature set in use rather than assuming nominal throughput values will apply to the final production configuration.
Resilience planning cannot stop at the simple failure case of a firewall appliance going down. In a distributed architecture, many other failure modes can affect traffic flow and service availability.
Examples include:
Vendor deployment guides often emphasize the most obvious failure case. Real enterprise designs need broader testing while the solution is being developed. The team should identify how traffic behaves when partial failures occur and verify that failover or traffic steering works as intended.
This is especially important when the architecture includes multiple virtual appliances, multiple metros, private cloud connectivity, and remote-site VPNs. The system may still be “up” in a narrow sense while some flows break, take an unintended path, or perform poorly.
Cloud providers often expose similar capabilities using different terms, defaults, and constraints. Those differences are not always obvious at the architecture-diagram level, but they can affect applications.
Azure ExpressRoute MTU was one concrete issue. Mikulasik called out an MTU of 1400, which may not matter for every workload but did affect some Civeo applications and required adjustments. He also referenced a past Azure behavior where UDP fragments between VNets were deliberately delivered out of order, a niche issue Civeo encountered.
The broader guidance is to read the fine print and test for low-level networking behavior early. Teams may not worry about these details during initial design, but finding them late can create application impact and rework. Provider-specific details can include terminology differences, protocol behavior, packet handling, MTU, fragmentation, and other conditions that only surface under real application traffic.
After deployment, Mikulasik evaluated the design against the original goals rather than only against the implementation plan. That distinction matters because deployments can drift from initial intent as teams make compromises under project pressure.
Civeo’s assessment was positive. The design provided the ability to support multiple clouds, pulled meaningful complexity out of individual cloud environments, and created the edge fabric the team wanted. It also gave Civeo flexibility that opened possibilities that had previously been harder to pursue.
One future opportunity is placing services closer to users where there is a clear service benefit. With a more flexible virtual edge model, those deployments become easier to evaluate because they no longer require the same level of physical infrastructure effort. Civeo also expects to use the Megaport platform more broadly as new products and capabilities become available.
Civeo’s migration shows how enterprise cloud networking evolves as business requirements and infrastructure options change. The first successful design is not always the design that should remain in place. Decisions made under deadline pressure, especially during a company spin-out or urgent migration, can leave behind complexity that should be revisited once the environment stabilizes.
The most important architectural shift was moving toward a flexible edge fabric. By using network as a service and Megaport Virtual Edge, Civeo reduced dependence on physical PoPs, preserved its firewall-based security model, and created a common place to connect sites and cloud services. That model gave the company a way to support multi-cloud requirements without rebuilding the network for each new provider or business event.
The operational lessons are equally important. Firewall HA, CPU impact, failure modes, MTU, packet behavior, and cloud-specific networking details can all determine whether a design works in production. A strong multi-cloud architecture is not only about connecting to more providers; it is about building a repeatable, testable, and flexible network layer that the organization can continue to operate as requirements change.
With a Megaport Solutions Architect
We’ve helped hundreds of customers, just like you, to simplify their connectivity.
