If you have not been following google groups and other discussions, this is a summary of the main differences between the original razor and razor-server. The new razor-server is a somewhat different beast than the original razor. If you go to the original git repo, https://github.com/puppetlabs/razor, you will find a note stating “TL;DR: Razor is being rewritten.”
I will not go into the politics of why razor is being rewritten, the google groups provide the official explanation here: https://groups.google.com/forum/#!topic/puppet-razor/q4uCVMmUop0
The main differences are in installation and usage, most things are different, and the new razor-server pretty much carried the name only.
When it comes to the technologies used, the new razor-server has gotten rid of node.js components and MongoDB. It is now based on JRuby, and, as the name describes, is a server. The server component is TorqueBox, which in turn is based on JBoss. I have not tried it, but I think this will allow razor-server to be more scalable in the future in terms of deployment size. Database used is PostgreSQL, and the different modes now allow for dev/test/prod instances to run on one server.
Razor-server still uses a microkernel, however, the new MK is based on Fedora rather than Tiny Core Linux. Naturally, this makes the new MK much larger.
One of the main things in the original razor was the state machine, which would let you know what state your nodes were in at any given time. At the time of writing, there is no easy way to accomplish the same in the razor-server, but there have been discussions about it, so who knows what will happen in the future.
Original server would collect facts about hardware using lshw. Razor-server does not utilize lshw, and the list of facts at the moment is rather limited. If you need special info about the hardware, you may need additional patches written for the razor-server.
The original razor ran on command line and as a razor service. Razor-server, on the other hand, runs in a JVM based application server, and all interactions with it are based through it is API. There is no need to curl all commands by hand however, since there is also a razor-client available. Razor-client is a command line tool to interact with the razor-server. The one annoyance with razor-client I have that it is super slow if it is using jruby. This means that you have to manage multiple ruby versions and take care that the client is not using jruby while the razor-server is.
In my opinion, razor-server is a little easier to use when it comes to configuring installers (also known as recipes or tasks) and policies, since everything can be passed as a json file instead of multiple commands on the command line.
Razor-server kept the concept of brokers, and currently supports puppet and chef brokers. No broker is still an option. Anybody can also add their own custom broker, however, there is a slight difficulty. Everything in the broker configuration will have to be stored as one entry in the PostgreSQL database. This is a problem if you need to have formatted files transmitted via the broker to the installed server. I had to solve this issue while writing the new Chef broker.
There is no path of upgrade between the versions of Razor and it is very unlikely that there will be one. These are essentially two different tools, both have great parts and the parts that are so-so.