What are you using for source control? That will inform how you move forward here. say you realize your footstep sounds are kinda big, instead of re-encoding all footstep sounds in the game (there could be a lot) you just have to change the one conversion settings shareset that all footsteps reference in the Wwise project. You can also dynamically adjust the conversion settings for entire categories of sounds while you're optimizing your package size-e.g. The reason you check in WAV files is so that you can do per-platform conversion settings, like full fidelity on PC and current gen consoles, lower quality on Switch. Your WAVs have to be stored in there however, so if you're worrying about source control hosting costs going up, that's kinda just the way it goes.

Though it may be beneficial to have the wwise project synced as well, it's smaller and WAAPI may scrape the WWU files for more detailed game sync information when Wwise itself isn't running.

That way folks can hear audio, but they don't have to pay the time cost of syncing audio source assets. Your sound designer will check in banks and metadata files generated from Wwise into a place that everybody syncs. It's common for large game teams, often using perforce, to put the Wwise project (or maybe just the Audio/Originals folder-your sound guy will know what this means) into its own special area in the depot that isn't synced for everybody. Main reasons for migrating: shorter build turnaround times, Plastic changeset IDs visible through the entire build process, more flexibility in build configuration.

Unity cloud build with plastic scm