In any project it's sensible to minimise the amount of change you do at any given time. So if you have an on-premise setup that works fine and just ticks along, you'd quite like to be able to set up the new cloud installation with the same configuration as the one you've moving away from (in fact ideally you'd want to be able to take replicas of your on-premise servers and roll them in as virtual servers in the cloud).
But can you actually do this? Well, it depends...
The thing you definitely won't be able to keep is your Internet IP addresses. Unless by some miracle the cloud provider you're moving to happens to be the ISP for wherever your servers currently live, you'll have to move your external world to a new IP range. Although it sounds like the hardest part of the exercise it's actually fairly easy: changing the IP address for your various Internet-facing services is simply a case of reducing the time-to-live of the DNS records (to five or ten minutes) well in advance, then making the change when the time comes, then cranking the time-to-live back up to its normal value once you're sure it works.
The main problems of changing Internet IP addresses tend to be on third parties' systems. Hopefully everyone accesses your systems by name anyway (so a change of IP will be automatically picked up in the DNS lookups) but the main gotcha is where third parties have your IP listed in an authentication table somewhere – an email server white-list, for instance, or a list of devices that are permitted to access one or other of their services. Such things tend to be listed by IP rather than by name, so don't be surprised if you have the odd third party problem. The fun part comes with internal addressing.
Internal IP addresses In a multi-tenanted cloud setup it should be easy for the provider to implement a network schema that allows customers to run their own addressing schemes while not trampling over their neighbours. The way to go is to give each customer at least one virtual NAT firewall at the “edge” of their virtual installation; as mentioned above the external Internet-facing address(es) will be unique and assigned by the service provider, but the internal Ips can be whatever the customer wishes. Because each virtual setup is behind a NAT firewall there's no problem with several virtual setups having identical internal addresses – they're entirely protected from each other and can't communicate except through the virtual firewalls and hence NATing from private address to Internet address and back again.
The trick with configuring your cloud network setup is to treat the virtual firewall as the default router. Depending on how your vendor implemented its network you may have to have two levels of NAT in order to accommodate all your subnets. If your edge firewall can have multiple IP addresses then life's pretty easy (for example if your provider is VMware-based, an edge firewall can have up to ten IP addresses). If, on the other hand, your edge firewall can have only one internal IP address, you'll have to create a separate virtual NAT firewall for each of your subnets, along with a “transit” network between that collection of firewalls and your main edge device that hooks into the provider's LAN. The point is that if you don't want to have to change your servers' IP configurations you'll have to ensure that you have an edge device that's configured with the address that the servers have configured as their default router.
The firewall permissions on your virtual firewalls will probably be quite liberal as they're really just acting as routers, but since you've just added a bunch of security devices to your virtual setup you ought to consider whether to implement routing restrictions to prevent unnecessary access between subnets – it's good practice to ensure that if your systems should happen to be compromised, the intruder can only use a server to jump off to the points it absolutely has to have connectivity to.
But what if the vendor provides the IP addresses? Some vendors have decided to make their installations so easy to use that they don't bother the user with “complicated” stuff like configuring IP addresses and routing. This is fine in principle, but it means that if you choose a supplier that has done this, you're going to have to change the addresses of your servers when you move them. This concept is known among network managers as “the ball-ache of the century”.
If your provider can't let you have the IP ranges you want, question them as to why this is the case. If they really can't do what you want, think back to what was said at the beginning: avoid changing too much at once.
How do you achieve this? Simple: why not evolve your existing world to the new IP addressing scheme so that you can test it before you move it? By changing your world and letting it soak in before you do the cloud migration you're avoiding doing two changes at once and your migration will be far easier and less hazardous than it would otherwise have been.
Conclusion You're going to have to change your Internet IPs: get over it, and plan ahead. Remember that you'll need to reduce your DNS TTL a few days prior to the migration to allow old data to be flushed from caches.
Understand the edge-firewalling your new provider gives you, and hence whether you're going to need to add an edge layer and a transit network, or whether you can just have the single edge device with multiple virtual interfaces (and hence multiple IP addresses). And if you really don't get to choose your own IPs, reverse-engineer the new installation's addressing scheme into your existing setup prior to the move so that you know everything's going to be able to communicate once you've moved it.
