Considerations for implementing LINQ to SQL or Entity Framework now, intending to use NHibernate later

Question

I've got a deadline for an initial release of a client-server application that will have lots of iterative releases subsequently.

NHibernate is the ORM of choice, largely by reputation and my desire to gain experience with it.

The problem is that I haven't even had a chance to spike NHibernate yet, and I'm afraid that doing so is going to throw me off track to hit the deadline. So, I'm thinking that I'll either use LINQ to SQL or Entity Framework for now, since I have some experience with it them, and then when I am able, swap out for NHibernate.

Given this scenario, are there any special considerations I should make when abstracting data access or designing the database schema to prevent big headaches when moving to NHibernate?

edit:

As the post to which Asad linked below points out, L2S is going to limit me to table-per-class, which might be manageable in a first iteration, but I don't want to go down that route. Let's assume now a future migration from EF to NH.

Answer 1

Following post will help you understand the difference and issues

• NHibernate vs LINQ to SQL

Hope it helps