Problem/Motivation
In Drupal 7 the decision was taken to remove profile module from core. Because it was taken very late in the release cycle, the module remained in 7.x but hidden.
Currently in 8.x, 6.x/7.x profile module fields are migrated to configurable fields on the user entity.
For sites like Drupal.org which make extensive use of profile module, this wouldn't be the correct choice - it's not simple to create multiple forms for a single entity for site builders, and all fields are loaded on entity load (and user entities for the current user are loaded on every page). So this has both UX and performance implications for migrated sites.
The recommended way to do extensive profiles is via a separate entity, which is provided by https://www.drupal.org/project/profile
Proposed resolution
Consider removing the profile -> user migration from core.
The disadvantage is that profile fields won't be migrated by default, however assuming a migration path to https://www.drupal.org/project/profile this could be put in the migration notes as the way to do it.
Alternatively we need to make sure the contrib module can/does take over the core migration when it's installed.
Remaining tasks
Decide...
Comments
Comment #2
Gábor HojtsyIMHO this would be better since we do have the migration path built (and on the verge to have the translations migrated too in #2225717: Add config translation support to migrations and implement for Drupal 6 user profile fields). This is sufficient for simpler sites. Don't know how to do that though.
Comment #10
quietone CreditAttribution: quietone as a volunteer commentedComment #15
quietone CreditAttribution: quietone at PreviousNext commentedActually, this would be better in the migration system, where the migrate maintainer work from.