Q:

Natively boot Virtualbox Image

I am faced with a Windows hardware/software problem left over from another person. It's on me to resolve. It's a mission critical setup. The situation is:
I've got a physical server machine with:
-Disk C:\ (one disk) containing a basic install of Windows Server 2008 R2, formerly Win Vista Pro, now gone.
-Disk D:\ (software Raid) containing a VirtualBox disk image of a configured Windows Server 2008 R2 running SQL Server R2 among others.
What shall I do now?

Migrate all the stuff from the configured VM to the basic but
natively installed C:\ Windows Server 2008 R2 (with the possibility
of breaking stuff)? Or, 
Setting up the machine to "natively boot" the VM with the help of
bcdedit.exe (something I've read about, what I've never done, what I don't know of if it
works, if it hits performance,  or if it is stable for production)

For me, being old skool, I am in the process of de-virtualising everything (option 1). But I'd be happy if someone suggests I am ok to go down the "natively boot" route.

A:

"I am in the process of de-virtualising everything" - really? o_O why? 
FWIW of your two suggested approaches, I'd migrate it but I'd be more than a little bit wary of this approach personally.
Your question is a little unclear: does the VM run now as it is? Unless you're having an actual problem other than being wary of virtualisation, my real suggestion is to actually leave it where it is, virtualised.
update to address comments
Ok, to address your comments, if the server is critical and currently running then I'd suggest borrowing "first do no harm" from the medical community. What I mean by that is that if you wish to change how this server is hosted at all, you should place the results of any migration onto a new server, so that the current server will be available as much as possible while you work on the new one, and so that anything you do cannot 'damage' the current service to your users. This approach will also allow you to take the time and do things right. 
If you can't get the budget to do this with a critical system then you may have just found the reason why your predecessor made what appear to be a few very questionable choices...
As for the suitability of virtualisation, I'd say that your predecessor was barking mad to run a mission critical system in a virtualbox install on a workstation OS, but that doesn't mean that there's anything wrong with virtualisation per se. This is not really worse than running critical servers on old workstations "because that's all we had around at the time" and I think we've all seen that happen.
I'm running most (about 60 servers) of our production servers on eight VMWare ESXi servers and our development/testing environments on 3 Microsoft HyperV boxes - these are both free 'server quality' virtualisation products (though you do pay for the fancy tools to manage a datacentre full of them) and I've never had unplanned downtime from either of them. Both of these also have tools that allow you to migrate/import currently running servers so this could make a migration very simple
So given what you've described, I'd suggest: 

Migrating the server to new hardware regardless of whether you choose to look at virtualisation with the 'right' tools or stay 'bare metal'.
Consider one of the "server quality" virtualisation tools, to hopefully take advantage of their migration/import tools to painlessly migrate away from the current, flawed, system.

A:

VirtualBox is almost certainly the wrong tool for server virtualization, but that doesnt mean that you shouldn't virtualize. If you have a Standard 2008R2 license, it allows for one host and one guest install. If it's Enterprise, you get 4 guests. 
Also, since you have 2008 R2, you have free access to the Hyper-V Server role. Hyper-V is an excellent solution that won't cost you any additional money. Unless you have a compelling reason to V2P your infrastructure, your "old skool" ways are going against the grain. 

A:

You cannot native boot a virtualbox image using bcdedit (you can set a VHD to native boot but not all images)  I'm not sure why you would want to "devirtualize" everything unless "old school" is somehow synonymous with "scared".  In short the whole "de-virtualize" idea isn't a good one.
If you really want to migrate this the best option I can think of is to power up the VM, use the Microsoft deployment toolkit to capture the image and redeploy that image to another machine (or the parent machine).  
EDIT:
If crashes are the issue on the VM and not the server, chances are the Hypervisor is to blame (without more details on the crashes of course). I would add the hyper-v role to the parent 2008R2 server, after capturing the image with MDT ,and then (in order of preference)

rebuild the troublesome VM and migrate the data
use the MDT to try deploying to the Hyper-v VM

