@Jason Shaeffer​ , I second @Ian Wolf​ 's recommendation for Community ad D2L support. Additional recommendations, assuming you are the admin for your hosted site:

• Brightspace org Structure: master it.
• SIS synchronization: What tools are you using?
• Content migration: How is it being done? What works, what doesn't? Plan to deal with the pain points while you can still go into your old system and hand-migrate what is needed.
• Consider locking down navigation, home pages, and course tools. We were the wild west on our old LMS. We used the migration to Brightspace as an opportunity to standardize. It made migration and training much more streamlined. We've never looked back.
• Set up "Migration CleanUp " Workshops for faculty. (This worked like a treat for us.) In advance, make sure you have brought up their selected courses in Brightspace and enrolled them. Provide a step-by-step process to correct expected problems and let them do it live, with facilitators walking around to provide over-the-shoulder guidance and support. Doing it while they still have access to their courses in the old LMS not only lets them retrieve things that don't migrate, it prevents "D2L ate my most amazing content" fantasies.
• Roles and Permissions: Understand the interaction between Account enrollment and Roles and Permissions. For cascading roles, consider the point of enrollment in the org structure, and the role at the point vs. role in the organization. For us, the SIS takes care of student and instructor enrollments into courses for our two most important roles, Instructor and Student. But various types of administrators and support staff get manually enrolled, sometimes through cascading enrollment. (Cascading enrollments are one reason to understand org stucture (above).)
• Identify instructor and ID workflows that will feel or work differently in Brighspace. Here are some things that puzzled our people: Grades and grade attachment, Rubircs and attachment, Content vs. files.

Best luck! I look forward to seeing you here in the Community.

Best of luck, Jason! As others have mentioned, the project of a LMS migration is quite the process with so many moving parts. I also would suggest starting small with your pilot and building on top of discoveries you find in each pilot. You will assuredly find lots of things during each pilot to improve on for the next pilot.

As Renee mentioned above, the absolute most important thing about the setup is your org structure, roles/permissions and how your SIS talks to those things. Those all impact the user experience and also the experience of your IT team and power users. The more you can automate the better! It takes some experimentation to get everything set up in a way that works best for your institution. Take your time, get feedback and test out as much as you can before launching to a large audience.

Your initial setup is crucial, because that is how you will later gather data and analytics. Be sure to think ahead as to what your end-goals are with any data needs and ensure you're configured to tackle that.

So it's been a while since I've chatted with anyone about this - but at a previous job, I helped migrate five different environments into one. The few big takeaways:

• Take the opportunity to rethink the way your courses are being delivered. This is a big chance to help people think about their courses differently, and a new environment can help them break free of habits that might be less effective. (the document @Aimee Whitefoot​  did can help with that).
• Think about the roles very, very carefully. At my current job, I walked into a set of roles that made little sense until I understood that they had been developed over the previous year in response to user demand. Know your users, and find the marginal cases and ask them about roles. And name them sensibly. "TA 5" doesn't tell anyone about what that role can do.
• Don't be afraid to ask D2L if it can be done by someone at support. Sometimes there's things that support can do, but don't advertise - so ask your Account Manager, Technical Account Manager or Help Desk if it can be done. Sometimes it can!
• Think about scalability - we're about 4000 courses per semester and 35,000 users per year, so decisions we made years ago (when we were slightly smaller), sometimes cause us some work later. Think about whatever decision you make as being wildly successful - what is the impact on yourself and your team (if you're lucky enough to have one).
• Often overlooked is with continuous delivery, the change management process for monthly updates can take a lot of time.
• Lastly, communication. Have a communication plan in place. Think through how you will notify people of changes in the system, outages, etc. etc. Some of that you'll have already, but continuous delivery means that you have to communicate every month at least... planning for that from the outset will help your users and yourself. Hopefully reducing unnecessary support calls!

Good luck, and as others have said, the community is great place!