Some principles/tips

Do not allow for new development in the old org during the migration unless critically needed. Establish a policy for communicating changes in the old org.

Before the migration - Make sure that the minimum test coverage is reached for every single Apex class and there are no @SeeAllData annotations (this could be a separate project). Otherwise, the coverage will not pass and you simply won't be able to deploy ApexCode into Prod with all dependent metadata (custom buttons, layouts etc).

Migrate everything. Data cleaning, Metadata cleaning, Unused fields removal - all this is a different project and must be performed before or after but not together with migration! A missing profile or a field or an installed package will have a huge impact on the speed of migration.

Prepare to resolve a lot of conflicts. Field references, User references, missing metadata, missing data..

Plan to spend time fixing hardcoded ids in Workflows, Classes, Validation Rules and Formula Fields after the metadata and data migration is performed. It can be a Record id, RecordType id, CustomField id etc.

Migrate all the installed packages using Force.com migration tool. Don’t worry about trial versions. When trial expires metadata won’t be deleted. For tests trial period is negotiable with package vendors. Double Check you will migrate packages referenced in code. Client team may have no knowledge about installed packages that facilitate background technical processes and may not be able to specify all the packages necessary to migrate. In case of no time to investigate references insist on migrating all of the packages anyway. Those that are not needed will expire their trial period silently without causing any problems later.

Engage client as much as possible. Delegate some tasks to someone on client side if possible (org wide email address confirmation, manual declarative tasks). Make them prepare test cases (at least the critical points) and then perform those tests.

Plan a lot of time for testing use cases and fixing to reach expected behaviour (substituting hardcoded ids, making apex tests pass).

Align carefully features that are enabled in the old org (e.g. Territory Management, Forecasting) and work with salesforce support in order to enable or disable features in the new org in order to make it as equal as possible to the old one. Again - If the client wants to change their feature set - this should be addressed as a separate project before or after the migration. Some features may not available in the new org like Site.com! Some user license types may not be available in the new org - create a mapping in order to migrate all the profiles.

When using Force.com migration tool to migrate metadata:

• for each metadata type deployment use git to track what metadata was changed/removed from original one in order resolve deployment errors and specify deployment errors in commit messages.
• Prefer a lot of small deployments. one metadata type at a time vs large one
• Just to remind. In order to migrate Profile settings you need to include other metadata in retrieve call: CustomObject, CustomField, RecordType, Layout,Apps,Tabs
• In order to migrate translations you need to include other metadata in retrieve call: CustomApplication, CustomLabels, CustomPageWebLink, CustomTab, CustomObject

Don’t deploy restrictive metadata to production before finishing data migration. You can deploy it first to a sandbox to perform tests. ValidationRule, Workflow, Trigger, ProcessBuilder Flow, AssignmentRule, AutoResponseRule, DuplicateRule

Before migrating reports and dashboards ask users to move their private reports to some public folder if they need to use them in the new Prod.

Tech tips

• Enable admin user that you use for Data Migration to edit all fields in FLS for data import. https://help.salesforce.com/articleView?id=000171207&type=1
• Enable Audit Fields Editing (https://help.salesforce.com/articleView?id=000213290&type=1) in order to set value in Created By, Created Date, Last Modified By ID, Last Modified Date

Tools for migration

• Force.com migration tool Use https://packagebuilder.herokuapp.com/ to build xml file that is listing all the API names of the metadata.
• Talend Open Studio. With Talend you can declaratively script your data migration. For example a rule to map RecordType ids from the old ones to the new ones. Or a rule to specify default OwnerId.
• Create git repositories to track changes both in the old and new orgs. Use export command of the Force.com CLI tool Do weekly export and review of changes in the old prod. Do export of the new prod at each migration step.
• Command line Dataloader (see this Dreamforce presentation)

approximate order of metadata to migrate

• org wide email addresses
• installed packages
• Profiles (name and license, standard permissions) and users
• Unsupported Metadata Types (manually), translation workbench settings, Chatter settings, territory management, salesforce knowledge settings etc.
• Data model: Custom objects (without validation rules), record types, List views
• Profiles (Object CRUD settings, FLS settings, RecordType visibility)
• Sharing rules and settings
• Permission Sets, Permission Set assignment
• roles, groups
• StaticResources, Documents, CustomLabels, BusinessProcess, Certificate,CorsWhitelistOrigin,CustomPermission,FieldSet,Letterhead,MatchingRules,Queue,RemoteSiteSetting, other Settings
• ApexCode (Classes,Pages,Components) (+profile access settings)
• Metadata dependent on classes - Layout (+profile and record type layout assignment), WebLink, ObjectActions
• Email Templates
• Apps,Tabs (+profile visibility)
• Enable Communities, migrate profile settings for Guest Site user and community user profile, enable necessary Apex classes and pages
• Restrictive metadata (ValidationRule, Workflow, Trigger, ProcessBuilder Flow, AssignmentRule, AutoResponseRule, DuplicateRule)
• Analytic snapshot (I couldn't deploy it automatically per salesforce issue and workaround didn't help in my case)
• schedule batch apex