Exchange 2007 and newer versions stop you from performing a domain rename. Since you say that you're ditching on-premise Exchange that's not a factor. That opens up the door for what I think would be a much easier process than any kind of creation of a new forest or domain:
Complete your migration to Office 365 and remove Exchange from your SBS 2011 environment.
Add a temporary DC to your existing domain and migrate AD (and all FSMO roles) away from the SBS server, demoting the SBS server back to a domain member in the process. (After this point you'll have 21 days to complete the migration.)
Perform the domain rename.
Add your permanent W2K12 R2 DC and demote / remove the temporary DC.
Rename / move the OUs (GPOs, etc) in AD to your liking.
Migrate any other functions away from the SBS machine and decommission it.
The temporary DC isn't strictly necessary, but I'd probably do it (because I'm superstitious). Domain rename sounds difficult but without Exchange it's actually pretty straightforward. If you're at all concerned mock up your environment using virtual machines on an isolated network and try it out (preferably using a real copy of your AD "harvested" from your production network and placed into the virtual environment).
You're going to have to ditch the default certification authority that the SBS 2011 setup created when you do this, too. Decommissioning an Enterprise CA isn't really that hard, either, assuming you're not actually using it for anything. (If you are, then no matter what migration strategy you take you'll need to worry about that.)
When you're all done you'll have a nice shiny new domain name, your OUs will look like whatever you want them to, all user passwords will be be intact, and all domain member computers will have intact domain trusts.
Planned, tested, and executed properly the production domain rename and migration could take only a couple of hours to complete. (Obviously, the time you spend up front planning and testing will pay immense dividends when you actually do the real thing.)
(I'd also export shares on the new W2K12R2 machine that reflected the shares exported by the old SBS machine, and I'd add the SBS machine as a DNS alias to the new server. Then existing shortcuts, UNCs, etc, will "just work" following the migration.)
Edit:
I don't know why people get so cagey around domain rename. You need to plan it out and execute it methodically, but it has been painless for me. I've done three production domain renames and had no problems (other than long-forgotten FQDNs in use in embedded devices that needed to be changed). Two environments had Exchange 2003 and one did not. One had a single DC, the other two had multiple DCs. I mocked-up the first two (the environments that had Exchange) in VMs, but the third I just ran on the production network w/o a mockup (because it was so simple-- single DC, no Exchange).
Here's that bullet point from above, "Perform the domain rename", broken down into steps.
In terms of Microsoft articles, I prefer: How Domain Rename Works The article contains a lot of superfluous background, but the basic steps are in there.
For a single domain forest with a single DC the process is pretty painless:
Decommission any enterprise CA root.
Create a new AD-integrated DNS zone for the new domain name.
Set the forest functional level to Windows 2003 or higher.
Run rendom /list to generate the forest description file (Domainlist.xml).
Edit the Domainlist.xml file to reflect the new DNS and NetBIOS domain names.
Run the rendom /showforest, which displays the Domainlist.xml file in a "friendly" way, and review the output to make sure you made the proper edits.
Run the rendom /upload command to install the new domain name into Active Directory. No rename occurs at this point-- you're just prepping AD for the rename. In a multi-DC environent this would initiate replication of the renaming instructions to all the DCs.
Run the rendom /prepare command to verify readiness to rename. In a multi-DC environment this command checks each DC to insure that they all have received the rename instructions. Renaming can't begin until all the DCs have replicated the renaming instructions. (It's necessary that the change happen to all the AD database replicas nearly simultaneously.) Once you've execute rendom /prepare you cannot add any new domains to the forest or DCs to the domain until you've executed rendom /clean (see below).
Run the rendom /execute command to execute the rename. This instructs the DCs to perform the rename. Each DC will switch their AD database into a single-user maintenance mode, perform the rename, then reboot back into a normal operating state.
Once all the DCs have completed the rename execute 'Gpfixup' with the appropriate old and new domain names to update any references to the old domain name to the new name in Group Policy Objects.
Change the primary DNS suffix on each DC because they don't change automatically. I don't know why Microsoft didn't have these change automatically, but they didn't. Reboot the DC again after making this change.
Reboot all domain member computers twice. This doesn't have to be done immediately (I kept a domain in this state for a couple of weeks). Domain member computers will "detect" that a domain rename has been performed and automatically update themselves during these two reboots.
Once you've rebooted all domain member computers twice execute the rendom /clean command to clear the rename instructions from AD and return the domain to a normal operating state.
Delete the old domain's DNS zone from AD once you've migrated any non-domain member records out of it.
Like I said-- a single domain, single DC environment is simple because you don't have to worry about replication of the domain rename instructions or being able to contact all the DCs.
As far as side-effects go:
You do need to be cognizant that domain DFS root names will change. If you have Group Policy Software Installation coming from domain DFS paths you're going to see reinstalls of software (because the Group Policy client will think the software isn't installed).
If you /clean the domain too early (before all member computers have been rebooted twice) you could run into a state where you have machines that need to be manually disjoined and rejoined to the domain.
In larger environments you're going to see increased replication traffic while the new DNS zones populate.
Best Answer
I haven't done an installation of Windows Server 2012 R2 Essentials into an existing Windows Server 2012 AD domain, but I just did an install into a Windows Server 2003 AD domain last week and it worked fine. I was able to join the existing domain, promote my W2K12 R2 Essentials machine to a DC, and then retire the existing Windows Server 2003 DC. It worked out just fine.
Were I in your situation I'd:
Join a temporary virtual machine to the domain (running W2K12 Standard in evaluation mode if nothing else)
Demote the current W2K12 Essentials DC back to being a member server
Move any files off the "C:" volume of the W2K12 Essentials machine you need to save
Reformat the "C:" volume and install the new W2K12 R2 Essentials software as a replica domain controller on that machine
Migrate files back to the new W2K12 R2 Essentials machine
Complete the installation process ending with demotion and removal of the temporary VM
I'd mock this up with VMs before I actually did it, just to be sure it all worked smoothly in real life. It looks like a solid plan to me.
I wouldn't do any kind of "backup / restore" of AD, or any type of AD migration. Using AD's existing replication functionality is the way to handle this problem.