Standard Policy for Sandbox Environments

Sandbox Purpose and Structure

A sandbox environment serves the primary purpose of testing and training. They are highly valuable during the initial implementation phase and remain moderately useful for ongoing tasks, particularly for training new users and testing new releases. However, it’s essential to understand that sandboxes are not suitable for accounting forensics, historical reporting, or configuring new settings.

Here are the key characteristics that define sandboxes:

1. Same Version / Code Base as Production: For effective testing and training, the sandbox environment should mirror the version and code base of the production environment.

2. Data Differences: Over time, the data in the sandbox may naturally diverge from the production data due to user testing. There’s typically no need to regularly refresh the core data, and historical data is often unnecessary. What’s required is just enough structural data to facilitate testing.

Notably, Microsoft uses the term “Sandbox” with specific design and protections to prevent license avoidance in a production instance. This includes measures like blocking certain background processes in a Sandbox environment.


CRM and Business Central Sandboxes

Dynamics CRM and Business Central are distinct yet integrated systems. Therefore, their respective sandboxes are separate, and they are not automatically linked. The process to correctly link these instances is complex and should not be handled by the client. As a result, akoyaGO only supports the linking of sandboxes that it has created and does not extend this support to client-created sandboxes.


Implementation

During the implementation phase, akoyaGO will provide a sandbox, unless both parties agree that it's unnecessary. This sandbox will be established during Gate 1 and will involve a one-time conversion of core data to facilitate testing. The process involves backing up the production instance and restoring it to the sandbox, ensuring that all configurations are replicated, resulting in identical sandbox and production instances. Following restoration, a specific process will remove targeted data, leaving a clean, smaller instance.

As implementation progresses, the akoyaGO Project Manager can request another pull of core data after Gate 3 (ready for Parallel), which will be included in the previously agreed-upon implementation cost.

"Core data" can vary by client but generally includes constituent, contact, chart of accounts, funds, and user information. It does not include gift history, grant history, journal entries, and similar data.

Post-implementation (30 days after going live), the sandbox will be decommissioned and removed by akoyaGO personnel.


akoyaGO, Inc.
Standard Policy for Sandbox Environments
Created Date: October 23, 2023
Effective Date: May 10, 2024
Last Revised: May 10, 2024