In that case porting FROM it should be simple. TO it would be hard if you're using all those fancy features of your current DB. That's why I eschew all the sirens from Oracle DBA's of "oh... but Oracle can do that too!" Keep database activities in the database and application activities in the app.
The problem is that MySQL deviates from the standards (all of them) in surprising and uncomfortable ways. porting from MySQL is fun, when, for example, your target database actually ENFORCES the constraints that MySQL accepted but silently ignored. MySQL doesn't have that feature, but it won't bother to tell you.
Postgres, Oracle, MS SQL all support a (very large) common subset of features, so if you avoid stored procedures and db-specific features, you can port among them easily. This is not true for MySQL.
In my experience, MySQL lets you get into a state where questions like "hang, on - what's the difference between a DATE of '0000-00-00' and NULL?" are commonplace. This makes porting from it... not simple.
Although I have no experience with MySQL, this kind of problems have to be resolved by using LINQ to SQL since every db type is automatically mapped to its .NET counterpart. The DateTime .NET type then has only one representation of null.
Or what you're saying is that if you store a date of zero VALUE to MySQL it could be magically replaced by NULL internally? That would be really crazy.