Configuration change tracking is a foundational discipline for any MES environment, but manual methods often bury meaningful changes inside large, hard-to-read transfer files. TrakSYS Snapshots address this by capturing the full configuration—including in-implementation source code—and committing it to a customer-managed, git-based repository on a schedule or on demand. Rather than simply archiving backups, Snapshots establish a continuous, reviewable record of what changed and when, enabling stronger change management, audit readiness, and governance across sites and environments.

Key takeaways:

Snapshots commit TrakSYS configuration changes to the customer's own git repository, such as GitHub or Azure DevOps
Each snapshot automatically surfaces changes against established baselines, replacing hard-to-read manual transfer files
Version comparison, tagging, and history are handled natively in git, with access controlled entirely by the customer

Why Configuration Change Tracking Matters

Every TrakSYS implementation evolves—configurations are refined, logic is adjusted, and solutions grow alongside the operation. But without a reliable record of those changes, teams lose the ability to answer basic operational questions: what changed, when, and why. That gap becomes especially costly during audits, troubleshooting, and handoffs, where reconstructing history from memory or manual files is slow and error-prone.

This Q&A explores how TrakSYS Snapshots capture configuration changes automatically and commit them to a customer-managed git repository. It covers how Snapshots work, the problems they solve, how version history and recovery are handled, and the governance considerations for multi-site deployments—providing a practical framework for building a durable, auditable record of MES change.

Snapshots: The Basics

Question: In plain terms, what does the end-of-day Snapshot actually capture?

Answer: The Snapshot captures all configurations, including in-implementation source code, and compiles that information into a defined set of files in the user’s target, git-based source code management system (e.g., GitHub, Azure DevOps, etc.). Each subsequent snapshot automatically shows changes across established baselines.

Question: Is the Snapshot automatic, scheduled, or user-triggered?

Answer: The timing will be set by the user via TrakSYS cloud settings and will also allow on-demand triggering from the TrakSYS Cloud interface.

Question: What does the generated report look like, and who is it built for?

Answer: The contents look like any other software development project's contents in a git repository. As for who the Snapshots are built for, the target audience is primarily technical contributors making changes, but anyone who is set up to see the repo contents can see the changes captured by Snapshot.

The Problem It Solves

Question: Before this existed, how did teams typically track configuration changes in TrakSYS?

Answer: Users could (and still can) track changes by manually checking database transfer files into a SCM system, but the changes were difficult to read. Because all the information existed in one file, it was very easy to overlook small changes.

Question: What's a real scenario where having a daily snapshot and change history would have saved a team significant time or pain — a bad change, an audit, a handoff?

Answer: It is useful in all of these scenarios. TrakSYS users—especially those in regulated environments—need to be able to note everything that changed between deployments as a part of the change management process. This feature, along with native tagging capabilities in git repositories, enables comprehensive change management documentation.

Version History and Rollback

Question: How is the historical record structured? Can users compare versions side by side, and how far back does the history go?

Answer: These features are all native to the git repositories themselves. Users can use tags to indicate which versions were deployed to production. The repositories allow them to view changes side-by-side or inline, typically with a single click in the web interface.

Question: Can a user restore or reference a previous version, or is the history strictly a record? What are the guardrails around that?

Answer: Along with the content represented as individual files for each configuration item, the database transfer file used to generate the output is also recorded in the Snapshot history in the TrakSYS Cloud. That said, the database transfer file is stored in a way that won’t just re-import without a manual step. These transfers include ALL configuration items for change tracking and do not respect excluded tables or columns like a normal database transfer.

As best practice, the Snapshot guardrails require that a person wishing to recover/restore a backup have access to the target environment and manually adjust the file for reimport, knowing it will overwrite the target environment.

Governance and Multi-Site Considerations

Question: How does Snapshot interact with role-based permissions?

Answer: Because the contents committed go to the user’s own git-based repository, the permissions for who can see contents are entirely in control of the user and in a user-managed environment separate from the TrakSYS cloud. The only part of the workflow that requires TrakSYS cloud access is the configuration of the repository connection, including the URL and access token, which are managed by someone who has access to TrakSYS cloud.

Question: For organizations running TrakSYS across multiple sites, does each site keep its own snapshot history, and how does this relate to Solution Studio and Template Transfer workflows?

Answer: Best practice is to maintain a separate repository for each environment where users want to see changes, i.e., one for each site or SIMS instance at each pre-production level of interest (e.g., development, QA, staging). For customers using Solution Studio, it can be beneficial to point the main and branch/solo instances to separate repositories for change tracking.

Practical Guidance

Question: Are there any performance, storage, or retention considerations teams should think about as snapshots accumulate?

Answer: The only performance consideration is the database load during the generation of the database transfer file as part of the scenario. All other processing is done offline in ephemeral Azure Functions.

Rather than in a Parsec-controlled repository, data resides solely in the customer-managed repository. While Git is very efficient at content storage, users who know an environment will have no changes for a very long period of time can prevent unnecessary accumulation by disabling scheduled Snapshots between projects.