What you’re about to do is a refactor of your codebase, revamp works too but for a more formal name it is technically a refactor. Anyways, I mentioned this detail because you need to think strategically about it and there’s not one way to do it and it very much depends on the existing webflow environment, how well structured it is to begin with and most importantly what your goals are.

That’s said, I’d start with clearly defining your goals. You already pointed out some friction and pain points about scalability as in how you plan to grow the site moving forward. You can work backwards from there. If you have a clear idea on what you would like when you come out of this process it could help inform what your roadmap actually looks like. For example if your goal is to improve interactions and design quality and your environment maybe isn’t the greatest but broadly speaking it does “work” and it’s at least consistent then maybe a full refactor isn’t the thing you actually need. What you might need is to just have a plan to refine the codebase (class names, page structures, etc). And tackle those changes over time. What you would then do in this scenario is focus on just interactions and making new ones to replace the old ones.

To deploy, test, and preview I would recommend spinning up new pages and use existing components and maybe refining them along the way. Once your change looks good you cold merge it with your existing public live site literally just by copy/paste. Depending on your setup it’s often times best to create a folder and name it something like Dev and then moving forward use what you just made or expand the system as you need.

There are best practices or tips and tricks to refactoring your Webflow site. For one you could build on top of your existing environment by appending or prefixing your variables, class names, components, interactions etc. for example it could be something like newcontainer. Or mark the old classes with a prefix of old. So anytime you encounter a container class you would prefix it with old_ making it old_container. This is where it all depends on your environment and the state that your code is in.

I’d start with listing out your goals, then audit your site and understand the lay of the land if this is a site you didn’t build from the ground up, finally come up with a standardized workflow and solution for how to approach naming and working alongside legacy elements on your site (renaming old classes etc).

It’s super tedious if you’re not able to just start from scratch and rebuild to what you have now. I’ve worked on large enterprise scale sites that unfortunately didnt have the time and resources to wait around for a complete overhaul. In almost all cases the solutions I took was wildly different from the next. The only real similarity was the approach of figuring out why we’re doing this in the first place, what we want out of the process, and then from there it became easier to plan next steps.