There are currently only two features that prevent Crowd from being plugged in behind-the-scenes to automagically manage logins.

1) Importing users must allow the existing password to continue being used. This point cannot be stressed strongly enough. It is absolutely crucial in a stabilized environment that plugging Crowd in behind-the-scenes must not be immediately noticable. This can be accomplished in a variety of ways. Please see http://forums.atlassian.com/thread.jspa?messageID=257245102 for some background on this feature.

2) Applications that are Crowd-enabled should not be required to disable user-management features. This includes allowing a new user to signup, change their password, reset their password, or other management features. It is possible that the application could forward the user to to Crowd-versions of these requests, but would be better to allow the application to use Crowd behind-the-scenes to do this.

Without these two requests, Crowd can only be used in a well-controlled environment, or one that doesn't have much history. Consider this: Would you want to back Atlassian's many JIRA instances and Confluence applications by Crowd as it currently stands (ignoring the side-issue of merging disparate userbases)? I suspect the current answer is no, as it would involve requiring all users to update their passwords, and cause many user-support headaches regarding how to setup a new user or change their password.