There is no 'good' way, really. They all have drawbacks. There are more pragmatic options than others, of course. In general, methods to consider individually or in part:
graceful degradation (Site can still mostly function on older browsers, though some features may break and layout may not be as nice)
require certain browsers for entry (can't use the site unless you upgrade)
fork the presentation layer (create a separate, stripped down acceptable version for the legacy browsers)
The first is preferred by most users, as they have to do nothing on their end. This can obviously be a drawback though, if the intent of the application is to push forward with newer technologies.
The second is preferred by most development teams, as they can focus on the standards and newer technologies without the burden of endless bug testing and hacking of the older technologies. In general, it can make dev and maintenance a lot easier, quicker and cheaper for the organization.
The 3rd is sometimes a useful option when option 1 becomes too complex but option 2 isn't viable. This allows the dev teams to still maintain a more pristine code base for the modern users, with a separate altered code base for legacy. It does split dev efforts, of course, but can sometimes be less time and effort than combining the code base into one monolithic mess.