Traditional - Follow the 7 Simple Rules. 

The traditional strategy for customizing SoftSlate Commerce is to follow the 7 Simple Rules for Making Customizations. Essentially the rules tell you which files it's OK to alter (most of them have "custom" in their name). Installing a future upgrade of the core application will not overwrite any of the custom files, which makes it much easier and safer to install them. The upgrades are distributed as ZIP files that include replacements for all of the core files, but do not include any custom files. There is still an unavoidable manual step involved of testing and potentially merging core changes if they affect your customizations, but the chances of an issue emerging are relatively low. This is method used by the SoftSlate team historically for the work we've done for our clients. It's tried and true.

Mercurial - Pull and Merge. 

SoftSlate Commerce also offers public read-only access to it's source control repository using Mercurial. Another strategy is to make changes directly in the core SoftSlate Commerce files, and when an upgrade is released, install it by pulling the changes from the Mercurial repository and merging them into the customizations you've made. Doing this increases the chances of a conflict in any given file. However, it allows you to leverage tools, such as TortoiseHg and the MercurialEclipse plugin, to merge the changes together.

Mercurial - Mercurial Queues. 

Another alternative that leverages Mercurial is to represent your customizations as Mercurial Queues. Mercurial Queues is a system designed to keep track of patches made to a project that has an upstream source of new changes that you don't have control over. This may fit the bill because SoftSlate Commerce upgrades are such an upstream source.