It\u2019s no secret that enterprises are looking at SD-WAN as the means for evolving their networks. The technology improves on MPLS with better agility, more capacity increased resiliency and, of course, cost savings. Those advantages are in much need; just ask anyone who\u2019s runs an MPLS network. They\u2019ll tell you about its high costs, long provisioning times, and susceptibility to last-mile failures.\nBut keep listening and MPLS customers are also bound to talk about the technology\u2019s rock-solid reliability. They\u2019ll hate the price and delays, but they\u2019ll love their SLA-backed performance and how the MPLS provider takes care of everything \u2014 the last mile connectivity, managing the backbone, consolidated billing and more.\nThe properties of MPLS services may be disliked but the packaging is still widely admired. And since networking professionals are conservative by their nature, there\u2019s a big draw to stick by MPLS. Yet, religiously clinging to the \u201cproven\u201d and \u201cknown\u201d is a good way to kill any real WAN transformation effort \u2014 and leave your company in the dark ages of networking.\nThinking through the \u201cpackaging\u201d then is essential for any WAN transformation. This means considering a range of issues, such as last-mile procurement and post-deployment management, which were inherent to MPLS.\nProcuring both primary and secondary local ISPs\nArguably the biggest change from SD-WANs to MPLS in terms of those \u201cpackaging services\u201d is in the last mile. Now enterprise will need to get involved with procuring, managing and paying for Internet last mile access around the globe. MPLS pundits (read the carriers) will tell you that\u2019s an enormous hassle anyone running a global network should studiously avoid at all costs \u2014 at least that\u2019s the popular refrain.\nThe reality is a bit different. While there\u2019s no question the one-stop shop of MPLS made global build-outs easier in many ways, it\u2019s also true that last-mile procurement may not as big a hurdle as many think. For one, your organization might already be juggling multiple last-mile providers. After all, best practice for legacy WANs is to connect branch offices with a primary MPLS link and an Internet backup. Some local ISP needs to be providing that line for backup.\nWhat\u2019s more multiple providers will gladly assume the burden of aggregated contracting, invoicing and billing. Expero, Brodynt, and Global Internet come to mind. In fact, many are the subcontractors global telcos will use to solve their own last-mile issues. Last-mile procurement may not be a show-stopper for SD-WAN, but it is something that must be carefully considered.\nPost deployment management and trouble-ticketing\nMPLS services are fully managed network services, which means your MPLS provider handles the network monitoring and troubleshooting \u2014 for a fee, of course, and often only after opening (and waiting on) a trouble ticket. How will that work with SD-WAN and multiple ISPs? A lot of it depends on the SD-WAN architecture. In principle, SD-WAN helps you get away from the fully-managed model of carrier services. The extent to which you move towards self-service, on one end of the spectrum, or full-managed, on the other end, will depend on the SD-WAN architecture.\nIf you choose to do the deployment yourself with SD-WAN edge appliances, you\u2019ll most likely have to shoulder the responsibility for troubleshooting networking issues. Depending on company size, IT expertise, and established processes this may not be such a problem.\nAs for services, SD-WAN services offer a different approach from the fully-managed carrier services. A co-management model allows both customer and provider to troubleshoot the network. It blends the benefits of self-service with a simple management console, and strong support and operations capability for advanced troubleshooting.\nDelivering co-management requires suitable underlying networking and security architectures. The SD-WAN technology is part of that solution, but for co-management to really be effective, it should include the security infrastructure as well. Many SD-WAN services, where carriers integrate and package third-party SD-WAN and security appliances as a service, are fully-managed or only provide co-management for the SD-WAN infrastructure not security. Instead, they will offer monitoring consoles for viewing and reporting on SD-WAN traffic flows but require ticket submission to change the network.\nSD-WAN delivered as a service (SDWaaS) where SD-WAN and security are converged into a software-based, cloud service (not a set of appliances on-premises or in the carrier network) will offer co-management in both domains. They put the end-to-end monitoring on the SDWaaS provider, but the security and SD-WAN management on the user. Since they provide the edge SD-WAN, SDWaaS providers can see when branches go down or are affected by an ISP outage, and alert you accordingly. The provider is maintaining the underlying network and infrastructure for all users; you\u2019re responsible for the management of your own network instance.\nThe how\u2019s of SD-WAN\nSD-WAN is a promising technology foundation for the future WAN, but any successful global deployments means carefully thinking though operational issues.\nHow will you procure last-mile connectivity without been awash in invoices in five languages and 10 different currencies?\nHow will you monitor, manage and troubleshoot those providers in a way that meets (or exceeds) your company\u2019s experience with MPLS?\nLuckily, there is an enormous range of SD-WAN options to meet a diverse range of needs. Selecting between them involves understanding how best any solution can address the \u201cpackaging\u2019 issues without compromising on the core drivers for SD-WAN \u2014 speed, agility, capacity, and cost savings. And that means looking past to the organizational beliefs of the \u201cproven\u201d and \u201cknown\u201d solutions or \u201cThat\u2019s the way we\u2019ve always done it\u201d to the benefit for your business. Because in this decision around WAN transformation, religion has no place.