Are there tools to help upgrade from DO 3.9 to 4.x?

Unfortunately, no.

Some documentation about the how to convert DO 3.9 features to 4.x

Again, no. And, frankly speaking, I fear we have no time on writing this guide.

But I'm certainly ready to answer on particular questions here.

like DataService

The most close analogue is Session.Services - see the description and examples in Manual.

sample how to implement RuntimeService

Currently we don't ship any close analogue, but provide more generic API for this: you must implement IModule in some of types you register. Its OnBuilt(Domain domain) method allows you to create a dedicated Session and thread for your own analogue of runtime service(s).

Also, you can subscribe to Domain.SessionOpen event there to intercept Session-related events.

sample how to implement Lucene support

We don't support Lucene; moreover, actually we're quite rarely asked about its support. So currently implementation of this feature isn't scheduled.

sample how to implement user/roles (and permissions)

Access control API will be available pretty soon as part of Xtensive.Practices (new namespace in v4.4 containing all optional stuff). Hopefully, by the end of this year in beta.

Btw, if you need something simple, you can start with your own model. Just create your own User and Role types and implement your own authentication, but leave ACLs and permission checks API to us. There is a big chance it will be available when you'll really need this.

I can add that likely we won't provide our own authentication API in this version. We'll just provide a way to say who's current user - something like this:

var accessControl = session.Services.Demand<AccessControl>();
accessControl.User = authenticatedUser;
var readPermission = accessControl.GetPermission("ReadObject");
accessControl.Demand(readPermission, someEntity);
var query =
  from o in session.Query.All<Order>()
  where accessControl.HasPermission(readPermission, o)
  where ...
  select o;

Remember this is just an example. Actual API should be different.

When i look at the examples all i can find are simple apps, same level as tests.

That's true - we tried to build simpler examples with this version - they're easier to understand for newcomers. Likely, we'll publish some complex examples later, but actually, I don't see a real need for this. Our current goal is to describe all the features - their practical implementation is actually pretty obvious.

Btw, if you're interested in complex BLL, see AuditAndOpenGenericsTest in Xtensive.Storage.Manual project (btw, v4.4 will contain it; currently you can view its version from v4.2 in Google Code).

I like to see an example with some business logic

Hmm, just checked and discovered we really never override event-like methods of Entity to show reaction to various events (removal, field value change, etc.). So we'll fix this.

Btw, AuditAndOpenGenericsTest gives some impression on what can be done: nearly any Entity-level event now has its Session-level analogue, and this relies on the second option to implement the audit transparently.

reporting scenario's

There is nothing special: you can use either our own LINQ query translator for reporting (we prefer this option), or rely completely on database structures and some third-party reporting engine.

UI paging

It's pretty easy with LINQ - .Skip(...) and .Take(...) methods solve the most important part in this case. Everything else (e.g. some high-level wrappers) is up to you.

See AspNetMvcSample2 in Sandbox projects - it shows paging over ~ 100K of entities. But there is really nothing special.

filtering large resultsets (with many tables involved)

Again, LINQ itself should work perfectly here:

• Our goal is to translate nearly anything you pass
• Your goal is to build filtering expression. There are lots of examples on this on the web.

login/logout

This isn't what we're going to implement soon - mainly, because this is pretty specific to a particular application. We thought about implementing membership provider for DO, but finally found this not so attractive: in any particular case this is pretty easy (~ 1 day of work), but since we must implement this in general case, it will be more complex, and moreover, we'll need to document and support this. So we decided to postpone this.

This explains why we don't implement other particular solutions, and that's why we extract Xtensive.Practices project:

• Obviously, we can't implement integrated solution for any particular problem developers face;
• But there are some common ones. We're implementing them in generic way, but now we always take into account maintainance and documentation costs. So if problem is really complex and common, there is a big chance it will be solved by us (e.g. ACLs and caching - in both cases the API we provide is good enough to implement them on the top of it, but we're anyway working on support of these particular scenarios), but if it's pretty simple (e.g. login/logout), we avoid providing integrated support for it.

exception logging in database

That's easy as 1-2-3: as far as I can judge, you should just catch it and log :) If this is done in the same transaction, nothing will be committed if the transaction will be rolled back because of this. Otherwise (e.g. if you're using separate Session) the error report will be persisted anyway.

rollbacked transaction issues

If you mean deadlocks and version conflicts, there are really no samples about this. Moreover, currently DO is incapable of reprocessing transactional method calls on deadlocks (but this will be done almost instantly of few users will vote for this feature here), so there is really nothing special. You should do this as you'd do this normally.

E.g. that's pretty easy with ASP.NET MVC; regular ASP.NET requires some hacks like we used in v3.X; WPF applications need either our own automatic transaction reprocessing or some custom infrastructure for this (e.g. any data fetch attempt must be executed as delegate passed to a special method providing transaction + reprocessing for this).

best practices to upgrade large application (maybe separate upgrade app), etc...

No, we don't recommend you to use a separate upgrade app. I'd recommend you to use the approach used by us in nearly all the samples - i.e. just build the Domain. If you'll need something more complex (e.g. first build it in Validate mode, and then, if user confirms this - in Perform mode), it's normally pretty easy to modify the code in accordance with your needs (e.g. few lines in described case).

But the topic seems really poorly covered, so I'll write a dedicated post about this soon.

Hopefully, this will help.