Davidson: If you follow a lousy standard, it’s better than making one up or following none at all. Also, it is harder to follow multiple patterns than it is to follow one standard.
If possible, consider incremental changes such as making physical tables that meet a better standard, and implement views that encapsulate your objects to look like the old systems. At PASS Summit, I learned a bit more about microservices. They allow you to have one database used by one application ideally, so if you do have poor practices, it only affects the one system and fixing things over time is (theoretically) more manageable.
Kline: Your question is a bit vague. I’m not sure if you’re asking for best practices about the migration itself or about the database design. I’ll postulate that you mean, “We’re going to migrate a database, and this might be a good time for us to refactor the design a bit to implement some more best practices.” If that’s true, there are a couple of things that I really, really, really encourage you to do. One, standardize your object names. Two, make sure data types are consistent for columns (in tables and views) as well as parameters and expressions (in procs, triggers, and functions) to minimize the risk of implicit conversions—a ninja stealth performance killer in SQL Server apps. Finally, I encourage you to make sure all tables have a clustered index, a primary key (possibly the same as the clustered index), and fully declare all foreign keys and create non-clustered indexes on them. The performance will improve.