I managed to successfully port my Visual Studio Achievements for Windows Phone to Windows 8 - it now fully works in the Metro environment with absolutely the same capabilities as its mobile counterpart (the Windows 8 version is mobile to some extent too, since Windows 8 will be used on tablets). This article represents a general overview of the process.
As long as the application is well-designed, it should not take much time to port it to Metro. So if you have a good separation of concerns and files are structured well in a solution, you can just copy and paste the necessary components, adjust the namespaces, update references and you are ready to go in a lot of cases. There are exceptions, that I will be talking about later in this article, but generally the most time-consuming part of the process is the threading model reorganization.
Recommended reading: App Porting to Windows 8 Already Possible
There is not much trouble with modifying references either. As I was moving code files from the Windows Phone project to the Metro one, I had to do slight modifications in the JSON parser that is now accessed through Windows.Data.Json, which is much nicer than its Silverlight counterpart, by the way, and I was not sure how I should refernce it.
As I found out later, all necessary references in a Windows 8 Metro project are available by default and the only thing the developer has to worry about are external references to third-party assemblies.
Recommended reading: How to: Add or Remove References By Using the Reference Manager
The whole concept of storage in the context of a Windows 8 Metro application is closer to the actual full-sized .NET rather than Silverlight. There is no Isolated Storage, but the developer can only access a very limited set of locations. It should not be a big concern when porting a mobile application because you didn't have full access to the actual file system in the first place.
Recommended sample: Windows 8 File Access Sample
All user interface is done via XAML, and if you have that ready on Windows Phone, you should not even worry about it on Metro because I managed to reuse 90% of the whole XAML stack that I had working as a part of the mobile application.
There are some binding nuances you should be aware of, though - for example, you cannot bind an Uri to an Image source. Instead, you need to pass a raw string. Not that big of a problem when used with a converter, but might confuse new developers who might not realize what is the source of the error.
Recommended resource: Designing UX for Metro apps
The same Visual Studio experience, the same nice debugging and deployment, unit testing and performance analysis. It might take a little bit to get used to the revamped UI color scheme and general Metro-ification, but from my own experience I can say that this takes less than half an hour. Although it might be a little bit unusual to see an all-gray chrome and icons, the location of the most used functions is the same and on an intuitive level I managed to find the commands that I used before.
Recommended download: Visual Studio 11
Same as the Windows Phone application, the Metro application declares a set of capabilities that are required for it to run. In a Windows Phone application, this model is framed by capabilities. In a Metro application, there are Capabilities and Declarations. Capabilities are the fundamental limits for the application - for example, if your app requires access to the webcam and microphone, you have to check those two options in the Capabilities list.
Recommended reading: Specifying capabilities for a Metro application
The Declarations are a bit more granular and can be tied to permissions, but won't necessarily go together. On Windows Phone I don't have to worry about the handled file extensions, while in a Metro app I have to make sure that my application is associated with the correct extension to open it locally.
Recommended reading: Activating Windows 8 Contracts in Your Application
This is a topic around which a lot of WinRT functionality revolves. Alerts, pickers and data handlers work asynchronously, so a lot of basic operations that previously were executed on the UI thread (e.g. MessageBox) now have to be called on a secondary thread. The plumbing is already done for the developer and all that has to be done is some methods have to be marked with async. Here is where your Async CTP knowledge might be of great help.
Recommended reading: Charles Petzold - Asynchronous Processing in Windows 8
The overall porting experience is straightforward and easy to the point where parts of it could be automated. Should a developer create applications that are released both for Windows 8 and Windows Phone? Yes. Can most of the code base be reused? Yes. Do both applications have to provide the same experience? The consistency of the UI is a given as long as you are following the general conventions, but you might also consider building a Windows Phone application that is a companion for its Windows 8 counterpart instead of a duplicate.