Wikipedia traces the first use of the term \u201cwrite once, run anywhere\u201d to 1996. A Google search turns up 139,000 occurrences of that phrase. So why is the dream of absolute portability still elusive 20 years after it was first described?\nThe cloud was supposed to make portability easier. In theory, fully virtual environments should reduce dependence upon underlying hardware, and cloud providers typically offer a choice of platforms and tools. Once an application is in the cloud, it should move anywhere else pretty easily, right?\nUnfortunately, no two IT environments are exactly alike and the cloud is no exception. Users may not know this however. When the IDG Enterprise 2014 Cloud Survey asked if switching from one cloud provider to another is more or less difficult than switching from one on-premise provider to another, 29% of IT leaders said it is more difficult, compared to 22% of non-IT leaders. More than 40% of the non-IT leaders said they just didn\u2019t know.\nIgnorance isn\u2019t bliss in this case. The reality is that moving between clouds can be very challenging. While cloud providers do all they can to make it simple for customers to move applications to their platforms, they don\u2019t necessarily make it easy to leave. Cloud computing is evolving its own unique brand of vendor lock-in, but there are precautions customers can take to make migration easier.\nFirst, understand that most cloud vendors don\u2019t want customers to have absolute portability because that would reduce their business to a price-sensitive commodity. Even if they did want to make migration easy, they must necessarily make choices that limit customer flexibility. The selection of hypervisors, operating systems, management tools, virtual machines and network configurations each present potential migration gotchas, and no infrastructure as a service (IaaS) provider is going to support them all.\nEven fully \u201copen\u201d environments have incompatibilities. For example, network bandwidth provided to virtual machines by one supplier may be different from that of another, which can have a direct impact on performance. Or two providers may use different versions of the same open-source operating system or database, creating unanticipated compatibility issues.\nThe best way to avoid cloud lock-in is to minimize dependence upon the cloud vendor\u2019s infrastructure. When moving to the cloud for the first time, you can reduce friction by searching for vendors that support a wide variety of platforms (that includes databases, development tools and network management protocols -- several versions of each) as well as pure open-source standards like OpenStack.\nYou can also create new applications on top of a hypervisor whenever possible and use high-level languages to buy you a certain level of insularity from the platforms below. Even better is to write applications using the new breed of containers, such as Docker, which are operating system- and hypervisor-independent. \u00a0However, for legacy applications that were created for a specific hardware\/software environment, you\u2019re going to have some customization to do.\nWhen moving between public cloud providers, test your application in the new environment before shutting off the old one. Make sure the service provider can simulate real-world conditions like transactions and simultaneous user sessions. Most applications run pretty well when there\u2019s only one person using them.\nConsider also the amount of data you need to move. If you have hundreds of users or millions of records in your cloud application, it\u2019s going to take time and money to move everything. Can you afford the downtime? That\u2019s also true for software as a service (SaaS) applications, which have the same interoperability limitations as their on-premise counterpart.\nBe sure users know that moving to public cloud is not a panacea. It\u2019s great in many ways, but the dream of \u201cwrite once, run anywhere" is still just that \u2013 a dream.