Mobile development is an interesting task and today if an app is available on one platform, chances are it will soon be available for other platforms as well. This is driven by the fact that the percentage of devices on the market is pretty much split among 4 major players: Apple with iPhone, Google with Android, Microsoft with Windows Phone and RIM with Blackberry. Developers want to reach out to as many users as possible with the same product. In this article, I am going to particularly focus on switching from Android to Windows Phone 7 and why this process isn't going to be hard. Everything mentioned here comes from my own experience, so feel free to add reasons.
Syntax (Java -> C#)
One of the initial barriers (although not the biggest) is the language syntax. Android is based on Java and Windows Phone 7 mainly relies on C# (although VB.NET and F# are also available) - both languages carry pretty much the same syntactic weight - similar data types and similar ways to handle objects, therefore you won't spend much time trying to figure out how to end a statement or link an object to a method. Believe it or not, this point alone saves you hours if not a couple of days worth of work to get yourself used to a new environment. Of course, the frameworks at their core are different - you will be working with many completely different classes and methods (besides, sometimes the hungarian notation from Java migth seem unusual in C# where camel case is used for default naming).
XML for UI
Android allows developers to build the UI in a declarative manner via XML. The visual designer in Eclipse will reflect the changes in the linked XML file, but you won't be able to directly manipulate objects on the screen. At least not to the extent you can do that in Visual Studio or Expression Blend. When developing Silverlight-based applications for Windows Phone 7, you will also use an XML-based structure to edit the UI - XAML (eXtensible Application Markup Language). In my opinion, XAML in a Silverlight project is easier to maintain because you don't have the constant linking to R.java that can mess up proper internal references. It is also easier to implement control styles and property binding (especially to collections).
Easier access to some controls
I already mentioned that general data binding and templating is easier. Add to that the fact that it is easier to manage control behavior via event handlers and it takes less hassle to set complex controls and control groups up. A good example here would be the map control. In an Android application, to set a pin or to execute a zoom a developer has to instantiate a MapController and manage the map itself via overlays. On Windows Phone 7, you are solely working with the control without additional linked instances.
Since Windows Phone 7 is a single OS version for now you don't have to deal with custom (read: updated) builds, therefore the overall environment configuration is a bit easier. There is a single emulator that has a pre-defined set of features and capabilities (can only be edited to some limited extent) so you don't have to worry about your application getting in some issues because you didn't expect a specific device behavior. Also, it is a bit easier to manage internal package references since you don't have to directly deal with the AndroidManifest.xml file to reference libraries.
This point is very subjective, but the performance of the suggestion engine in Eclipse is pretty poor compared to Visual Studio. IntelliSense can speed up development a lot and sometimes it's easier to start typing a class name and simply accept what's suggested. To this moment, Eclipse doesn't suggest class names (however, it looks at associated methods and properties) unless those are referenced directly from a namespace. At the end of the day, it doesn't really matter to me as long as I know what class I want, but it's a nice bonus to have.
These are just some of the points and I will try to update this list as I am working more with both platforms.