It's a fact of IT that specific technical problems are created by aging systems. In many cases, the advantages of keeping the system outweigh those problems. However, if one could migrate away from the problems while keeping the advantages, then you are looking with the ever golden, “win win” situation. This document aims to help you decide when and if to migrate your Unix or OpenVMS systems and what platforms and destinations are good ideas.

Anytime you switch your OS, your server platform (meaning hardware or a new virtualization platform), or you change the physical location where your servers operate, then you are considering a migration. Here are the most common scenarios we see:

1. Move to newer version of the same OS
2. Move to a faster server
3. “Swing” migrations between data centers from old to new servers
4. SAN Migrations where the storage is being upgraded and servers have to get off the old SAN
5. Full OS migrations where folks are switching from older Unix systems to Linux
6. Ring fencing migrations where classic servers are put into a more secure environment that allows them to keep running in regulated environments.
7. Moves from unclustered to clustered configurations with OpenVMS or Unix-based clusters.

Migration is almost always an expensive, time consuming, and often frustrating process. It also almost always creates a productivity drag as folks adapt to the changes. Sometimes, the cost:benefit analysis works out, and other times it doesn't. At PARSEC we have done a large number of migrations and we see both clever and not-so-clever decisions being made. So, let's look at both sides of the go/no-go decision to migrate, first.

Great Scenarios to Migrate

1. Your application software has not changed much but exists on more modern platforms in basically the same form. This would be the case for things like Oracle, DB2, SAP, HANA, Apache web servers, Oracle Applications, and any multi-platform (multi-OS) application software. The newer platforms are cheaper and faster and your data and application can run unmodified on them.
2. Your application is running out of performance or has been low performing for a while and you can simply upgrade the hardware, copy over the app data (perhaps along with an OS image) and get a performance boost easily.
3. Your hardware is no longer supportable and/or you have lost your technical staff who knew how to fix, upgrade, or extend it. You are cheese-in-the-wind with no real plan-B if those systems or system fails.
4. You see an opportunity to move from a very expensive operational model to a much cheaper one and the cost advantages are so strong they will pay for themselves in respect to the migration costs.

In any of the “Great” scenarios the key is that the advantages overwhelm the drawbacks or increase your productivity or efficiency dramatically. These are “no brainer” reasons where if you find yourself in any of those circumstances, it's probably a great time to migrate.

Fair Reasons to Migrate

1. You want to move from an older operating system to a newer one (but it's the same OS). You might want to do this because of access to patches, features, or because it's easier to get support. Just keep in mind that you might also get away with ring-fencing your existing server more easily. You might also not need OS patches if your server has been fairly well locked down and only has one very specific job. It mostly depends on your need and regulatory requirements.
2. The application vendor is threatening to withdraw support for the version you use. This is pretty common for example with Oracle. However, keep in mind that vendors have been aggressively updating their business models to try and prevent customers from outright owning a copy of their software. Notice everyone wanting to rent you cloud servers and cloud applications? Perhaps that's because they make more money that way. So, consider how much you actually have used that support and how critical is it to your operations? Do you have technical staff that already knows what they need to about the product? Do you have known-good configurations you can restore? If so, you might not need that application support much.
3. The server hardware is aging quite a bit. Just consider that emulation is almost always more expensive than buying a spare server (with some notable exceptions like migrating a VAX into SIMH which is free). So, if your concern is just because of the age of the hardware, check to see if a used hardware vendor or Ebay has any spares you could buy. If you have technical help who can hot-rack the server, that's your best bet to soothe your fears. After all, if your prod server fails and you've got a hot racked spare already sitting there ready to go, very little can beat that as a disaster recovery option. Though, to be fair, if you have the budget you could create an emulated spare, too.
4. Your company is moving to a 100% virtual environment. You may be forced to migrate due to some kind of corporate initiative. Occasionally, some folks feel they'd be better off outsourcing everything related to IT and you have to migrate because, well, you are being forced! So, despite how you might feel about it, you have no choice. The same applies to forced geographic moves.
5. You can no longer get any security updates or patches for the OS. Just keep in mind that you have two other options you might not have considered. One is version locking and the other is PARSEC patches for extended support.

Possibly Invalid Reasons to Migrate

1. You feel the OS version is too old. It's still supportable (PARSEC supports almost all old versions of Unix and VMS). As we all know, feelings don't generate profits. Many folks would like to have a new car every year, too, but they don't upgrade because their old car is still running fine. The same applies in IT. If you have no burning need, why spend company resources on upgrades you don't need? Is your company making money having people perform those upgrades? Will the upgrade make them more profitable? Highly doubtful.
2. You feel like virtualizing your application for fun. Virtualization is cool and can be fun, but doing this should be project driven and result in some kind of substantive advantage or features you will use. Keep in mind that, for classic systems, the virtualization and emulation options can be rather weak (performance wise) and can also result in less stability. For example, we've seen lots of problems with people who use an Alpha emulator (like Charon-AXP, AlphaVM, or vtAlpha) inside of VMWare. The emulator will lose CPU ticks, then the OS is impacted and often crashes.
3. It's old. Well, diamonds and Frank Sinatra are old too. We do notice that sometimes younger IT people or business minded folks often see the age of a system as a liability. However, consider how long the company has been benefiting from that system sitting there and just doing it's job without additional charges or effort. Consider that, over the years, many of the bugs and problems with the system got worked out. It's also probably familiar to many of the end-users and changing it might pinch productivity and morale. It's not always great to swap out some “old” server until you consider technical and operational pros and cons of doing so.

There are several strong emulation suites for Alpha hardware. Let's just list those out first.

• AlphaVM is pretty much a clone of Charon. Comes from some type of schism in Stromasys and the fact that EU software patents have a short lifespan versus the USA. Word is this is a much smaller company than Stromasys (makers of Charon) that basically sells their software at a discount. I'd imagine they have a smaller support organization but word is the price is much better than Charon. It's unclear if they have the same performance as Charon (probably since it's mostly the same code base). They have multi-platform support including a few (like FreeBSD as a host OS) that Stromasys doesn't support.
• FreeAXP and Avanti This emulator is one of the least expensive. It's available on Windows only, though. FreeAXP is even free for commercial use which is cool if you can live within it's limits. If not, then use Avanti.
• Charon-AXP This emulator is probably the most well known. The company behind it (Stromasys) is fairly large with a global presence, support center, and a fairly healthy future roadmap. In testing at PARSEC, their emulator was definitely the fastest, but still couldn't beat a fast EV7 Alpha (no matter how fast the host machine). The downside is that their prices are comparatively very high. They charge many times what it would cost to simply buy a handful of spares or a much cheaper emulator. They are also one of the few commercial emulation companies big enough to have “corporate” problems, though vtAlpha / AVTware is close.
• SIMH is a free emulator for a LOT of hardware platforms but they have excellent VAX emulation (accurate) and they are working on an Alpha emulator, too. However, their emulation tends to be the slowest as they focus on accuracy more than performance. It's also a freeware project and commercial support isn't available. So, for a production client, it's probably best to have hardware spares as a backup plan in the first few months after your deployment. Also be aware that newer versions of SIMH (rather than the “Classic” version) have 2x to 3x as many hardware platforms available. They've made big strides lately.
• Qemu is an excellent emulation platform for a large number of processors and hardware platforms. They are working on an Alpha emulator but it is not yet functional for OpenVMS or Tru64. So, at this point, it's a non-starter for most folks needing stable emulation. Still, it's worth watching.
• vtAlpha is a product from AVTWare and Vere Systems. It's somewhat unique in that it's a “bare metal” emulator which installs it's own version of Linux as the host OS and then proceeds to setup the emulator and the GUI as an integrated whole. Their prices are significantly lower than Charon, but the emulated alpha performance is slightly lower and individual platform support is somewhat more narrow with vtAlpha. Also be aware they sell vtVAX which is a VAX emulator with the same design and features as vtAlpha.

So now that we've covered a bit of the basics, let's dig in with a table. Keep in mind performance is partially dependent on the real x86 hardware you pick. The performance section is highly variable and difficult to quantify. Personally, I remain convinced that none of the emulators can touch the EV7's performance no matter how fast your host machine is, how many cores you pile on, or how much RAM you throw at the emulator.

Maybe. Let's talk in terms of scenarios and showstoppers and give some examples.

Terrible Migration Scenarios

• You have an old Unix or VMS machine and it's connected to an old storage array, SAN, or custom hardware like LAT based terminal servers or serial concentrators. Emulation gives you few options to integrate the new hardware. Yes, SCSI pass-through works, but it's not going to help you with non-SCSI hardware that cannot be emulated like WAN/ATM cards, or high speed controllers like Infiniband or Myrnet.
• You have a GS1280 (baddest king-daddy Alpha server ever made) with lots of EV7 processors. You had to buy that thing because it was the only beast capable of handling the load. You have alpha-only binaries for VMS or Unix and can't port them. You'll hate emulation. It'll be less than half the speed of your GS1280. Those big Wildfire line of servers will stomp the guts out of emulation's performance. Do not believe any emulation vendor that says otherwise, they are likely exaggerating greatly.
• You make very heavy use of MSCP based RAID controllers and you want to emulate those as well: Don't. There are better options when moving to emulation.
• You have some development environments on your VAX and some non-critical servers you'd like to ditch the hardware and emulate. Well, emulation is a good option in this case but why pay big bucks for it when SIMH is probably the best VAX emulator (free or otherwise). You should be using SIMH for free. It's easier to make work, has accurate emulation, generally results in some performance gains, and has a more sane and accessible system than the commercial VAX emulation suites. If you can get by without having support, then SIMH is always a better option for VAX emulation. The two commercial options should be 2nd and 3rd in that case.
• You have moved most of your infrastructure to VMware or something similar and now you want to emulate your Unix or VMS hardware so you can move that to VMware too. That's not a great reason. You are going to probably spend (lots) more on the emulator than real hardware. So, is it really worth it? Also, running emulation inside VMware is something the emulation vendors love to crow about. Unfortunately, they like to ignore all the bugs and problems that causes. For example, if VMware short-changes your guest VM on a CPU tick what do you think the emulator is going to do? Let me answer: nothing good. Often we see VMS bugchecks and Tru64 kernel panics for this exact reason. Folks too high on VMware tend to make some fairly poor decisions just to shoehorn everything into VMware.
• You read the word “Cloud” in CIO magazine and now you are all excited to “move everything to the cloud”. You are so excited, in fact, that you are willing to try to run the emulation package on an AWS virtual machine or some kind of “cloud” provider. Well, how is it “cloud” when they don't provide you an API to control the guest OS, but rather the host? You get nothing but an over-compliated VPS in that case. Right now, there aren't any truely cloud-aware emulation suites. What they do is manually run the emulator an a virtual Linux server. Nothing any more magical than that. Don't drink the whole bottle of “cloud”-aid and try to force a square peg into a round hole.

Here are some scenarios that would be excellent migration scenarios.

• You have an old VAX or Alpha with no special hardware, the system isn't under heavy load, and all you really need is a box to run some old application software or host a legacy database. The system just sits on a single IP and runs it's application from local disks. You'd probably be happy with any emulator in this case.
• You have an old Sun box and it's presence in the data center is getting you dinged by security and other IT groups because of it's age. You know that running the hardware is cheaper than buying an emulator, but your problem is more than financial. You must get rid of that hardware so you stop being hassled by the clueless security people who (incorrectly) believe old systems cannot be secure or made secure. So you are willing to pay extra to have the hardware go away while keeping the OS and applications it runs. Remember when it comes to Sun, your only valid option right now would be Charon-SSP and it's super-expensive. So, it has to be worth it!
• You have VAX systems in your environment and need development and non-production emulated instances to help with writing software or day-to-day testing. By all means, go get SIMH and you'll be pleased.
• You have an HP3000 PA-RISC box running MPE and HP's chaos has left you out to dry. You are worried that hardware might fail and you can't always get HP3000 parts anymore. They were rare systems to begin with. By all means get out your checkbook and be prepared to write a very large one for Charon-HPA.
• You are a sysadmin who just wants some dev environments for his AIX systems. Put in the effort and get Qemu running. It's not that hard to get AIX 4 through AIX 7 working on Qemu nowadays. Sometimes it requires a mksysb image, but that's not too terrible.