We are at the tail end of introducing Webpack to an ~8yr old codebase and this has been our approach:
* Allocate training time for all team members to go through some e-learning courses / tutorials about Webpack (Frontend Masters, egghead.io, etc) and UMD (assorted tutorials / blog posts)
* After much hand-wringing we decided that for our situation converting our all-over-the-place JS codebase to UMDs with global fallbacks was the most flexible approach. This allows us to use the same code both in Webpack bundles and in our existing litany of tags. Introducing Webpack has forced us to pay down a lot of technical debt during the process, something that has been years overdue but had to get done eventually. It's been frustrating having to clean up the mess made by developers who no longer work here but ¯\_(ツ)_/¯
* Created a long-running feature branch where we added Node.js and Webpack dependencies to our existing Java / Spring / Maven project
* As internal libraries are converted to UMD, merge them into the feature branch and add them to the appropriate Webpack bundle. Any 3rd party JS libraries that are available via npm have been removed from our codebase and are now pulled in as dependencies via package.json
* Put everything behind feature toggles
* Experiment with our CD / CI pipelines using the Webpack feature branch to make sure we can reliably break the Maven build when something goes wrong with Webpack / Node.js, generate fresh bundles for hot / partial deploys, and get things deployed to an app server in one of our dev environments without any issues
* Do demos every 2-3 weeks for both our team and other teams / managers to show progress, share lessons learned, etc
All of this has unfolded along with our regular workload over the last 3 months or so. We've taken a measured approach with small steps along the way and it's worked out well.
A lot of people are off for the holidays so my guess is we'll start introducing Webpack bundles into production sometime in mid-late January.
As an added benefit, this project has been used to establish a bit of a beachhead with respect to introducing Node.js to our various codebases so we can start doing automated testing, modern JS dependency management, code linting / style enforcement, and providing better developer tools to the team(s) that write JS / CSS / etc.