Running a go-live project

This page is for the integrator who puts MyZapp into service at a customer's. It chains the steps of a project, from scoping to the switch to production, and points each one to the page that details it.

Scoping

• Three instances: a development one, where the settings are built, a test one, where the customer validates them, and production. Settings go from one to the next through a GOLIVE, always pulled by the receiving instance: test reads development, production reads test (see "Prepare the source instance of a GOLIVE").
• Licenses: each instance has its own identity and its own licenses. A module without a license on an instance receives nothing there (see "Managing the instance licenses").
• Project follow-up: the Projects module can carry the project itself, with its tasks, milestones and team (see "Steer a project" and "Follow a project").

What goes through the GOLIVE, and what does not

Before planning, sort each need into one of these four families:

• settings (processes, forms, catalog, ticket reference data, templates, menus, knowledge bases, CMDB object types, CRM rules…): they are built in development and promoted by GOLIVE, on selection;
• what is specific to each instance (addresses, connections, secrets, licenses, agents): it never travels, and is set on each instance;
• business data (tickets, requests, CRM accounts and opportunities, assets…): it does not go through the GOLIVE, but through data migration;
• execution traces (logs, histories): they stay where they were produced.

Accounts, groups and their members, and permissions do not travel either: a promoted item only designates the group or account it expects, and the target finds it locally.

Building in development

1. Create the groups and set the permissions on each instance, with the same codes: they are not promoted. Menus, on the other hand, are.
2. Build the settings: service desk, catalog, forms, processes, content.
3. Load demo data if needed to try the settings on realistic cases (see "Loading demo data"). Do not load it in production.

Preparing the data migration

Data from the former tool is migrated through the modules' imports, for example:

• tickets: import of a JSON file, each ticket becoming a new ticket (see "Import and export tickets");
• CRM accounts and contacts: CSV or Excel import with duplicate detection (see "Duplicates, merge, import and export").

User accounts must exist before the data that refers to them: a ticket whose requester cannot be found is skipped. Create them first, by hand or by synchronizing a directory (Active Directory, Microsoft 365 or Google Workspace).

Repeat the migration on the test instance, with real data, until the report shows no rejection.

Testing

1. On the test instance, declare development as the source (see "Declaring the source of a GOLIVE").
2. Choose the items, preview, resolve the blocking gaps, then apply (see "Choosing and previewing a GOLIVE" and "Applying a GOLIVE and viewing the history").
3. After checking them, reactivate the triggers of the To reactivate list: they arrive disabled.
4. Have the customer validate the settings and the data migration. A fix is made in development, then goes through a new GOLIVE: do not fix directly on the test instance what must go to production.

A successful GOLIVE can be undone from its history, in full or in part, if testing reveals a problem.

Switching to production

1. On production, declare the test instance as the source, then apply the validated GOLIVE.
2. Set what is specific to production: connections, mailboxes, secrets, licenses.
3. Import the documentation shipped with the version (see "Update the documentation").
4. Run the final data migration, then reactivate the triggers of the To reactivate list.
5. Check the instance (see "Monitoring the instance") and keep the GOLIVE history as a record of the switch.

After go-live

Changes follow the same path: development, GOLIVE to test, validation, GOLIVE to production. The Modified since option of the GOLIVE page only shows what changed in the source since a date.

To train the customer's users, the Academy offers learning paths (see "Designing an Academy learning path").