Tecnopolis Enterprises is pleased to offer a service to help those who want to upgrade / migrate their Fedora (or RHEL-based) systems from 32-bit (i386 / i686) architecture to 64-bit x86_64 without having to do a complete reinstall or run Anaconda. Yes, we have figured out a method to upgrade architecture in-place that can be done over a network even on headless systems, without onsite access being required, and without having to boot off DVD or USB media!
Yes, the upgrade you want is possible, and it can be done cleanly without leaving behind a mess or a "franken-system" the online forum peanut galleries insist will result. We needed to do this for dozens of our internal systems and we spent a lot of time developing and perfecing the method. After the upgrade no one will ever be able to tell it was once 32-bit.
I won't go into why you'd want to upgrade to x86_64, as if you are reading this, you already have the answer to that question! The time has arrived that there is zero reason anymore to run 32-bit (even with PAE) on a 64-bit capable CPU. We found that PAE kept getting buggier and buggier to the point of becoming unusable, especially on each progressively newer hardware setup. When we discovered Linus said PAE on systems with over 2GB RAM was "stupid", and that kernel devs don't help with PAE bugs unless you bisect them yourself, we knew we had to develop an architecture upgrade method.
We have tested and used in production our architecture upgrade method on Fedora 24 specifically. It should also directly apply to Fedora 25 and Fedora 26, which we can test as required (just ask!). It should be possible to use the same method for RHEL 6, and maybe RHEL 5, as well as RHEL derivative systems like CentOS. Again, we can pretest as required.
During our research we found mentions of some old methods for things like Fedora Core 5 and Fedora 10, but they relied on tricks in yum, rpm and Fedora that are no longer present. We didn't want to come up with a method ourselves but in the end there were no google hits of anyone attempting this upgrade with modern Fedora, so we had to develop it ourselves. Also, a couple other distros, notably Arch Linux, have some good articles on how to upgrade, but since they don't use rpm/dnf their methods don't carry over to Fedora.
Fedora is always blazing forward with new changes and it is very possible a new version may break or disallow our method (like they did the F10 method), so I strongly advise anyone who wants to do this upgrade without a full reinstall do it sooner rather than later.
What's the cost? $250 USD per computer. If you have multiple computers, excellent bulk discounts are available. That price includes all the work required to get the base OS (i.e. all packages that come from official repos) upgraded, as well as most packages in tightly-coupled repos like rpmfusion or EPEL. Packages outside that scope may require manual intervention on your part, and are handled on a case-by-case basis. There are a few other corner cases such as binary-file-format programs that we can discuss before the upgrade.
Can you provide the instructions so I can do it myself? For a negotiable fee we can provide you with instructions (high and mid-level, with much low-level) which you can use as much as you wish on your own computers. If you are a VAR or service provider who has customers lined up for this service, you can work with us as a reseller. Any advanced-level Linux admin should be able to follow the instructions and work past any issues, and we'd be here to help out if you get stuck. Before the instructions are passed on, signing an NDA limiting redistribution would be required.
Why so expensive? Why not free? We fully believe in open source and free software, however Tecnopolis Enterprises is a small company in the business of helping people with Linux, and to stay in business we have to charge for services. The 32 to 64-bit upgrade is pretty esoteric and there is a dearth of information about it on the net. Further, the gurus who could come up with the procedure clearly don't care one bit about it and actually don't understand why we don't just wipe and reinstall. Of course, we know better, as anyone who is faced with reconfiguring a highly-tweaked system is looking at blowing a week of work on it, knowing that they'll forget many little hidden things that will bite them for months (we know, we did that for our first system!). Since our method saves at least 10 to 40 hours of work, we feel we are providing excellent value.
How does it work? If you want us to do the work, we'll need remote ssh and root access to the computer. Since one should never do that lightly, we can provide references on demand. Our owner, Trevor Cordes, is highly respected in his local Linux community, Vice President of his local UNIX User Group (MUUG); and our company, Tecnopolis, has been in business since 1999 and highly Linux-focused since 2001. Alternatively, if you opt for the instructions-only method, no access will be required as you'll be doing the upgrade yourself. In any event, it is strongly advised you perform a full disk-level image backup before any upgrade. If you have an external disk of similar size, you can boot from any Linux USB boot distro and run dd to create an image. While we haven't had a single botched upgrade in all the production boxes we have done, the upgrade is necessarily quite risky and it pays to have a fallback. If backing up is too onerous, it is not required, and we can discuss mitigating techniques and fallback ideas beforehand.
Because of the nature of such an upgrade, Tecnopolis Enterprises and Trevor Cordes assume no liability for any loss of data, downtime, loss of use, or any other loss. The upgrade is performed on a best-attempt, as-is basis with no guarantee of success. While it has worked in all of our attempts to date, the differences in systems are so numerous and complex that it may not work in yours. This is why having a disk image backup is strongly advised as you can fallback to a working state if an upgrade fails.
Email email@example.com with any inquiries or for more details.