Implementation lifecycle

superglue follows the steps an experienced consultant already uses, from the implementation plan to the handover. The agent does the reading, drafting, data and configuration work. You make the decisions and grant every permission to write to a client system.

The lifecycle

An implementation has 11 steps in three phases. Each system page on the website explains the steps for that system, and each migration guide explains one source and target. These docs cover how you run each step in superglue.

Phase	Step	How to run it
Pre-implementation	1. Implementation plan	Project setup
	2. Discovery	Discovery and Project context
	3. Data assessment	Data assessment
	4. Solution design	Solution design
Implementation	5. Configuration	Configuration
	6. Data mapping	Data mapping
	7. Data migration	Migration and cutover
	8. Testing and UAT	Testing and UAT
	9. Cutover	Migration and cutover
Post go-live	10. Hypercare	Post go-live
	11. Handover	Handover

Connect the client’s systems when a step first needs them. Private and on-premise systems connect through the secure gateway. See Connections.

Discovery

Discovery workshops decide what the client needs from the target system. Connect your meeting notetaker, Slack or Teams, and email on Brain > Setup, so the agent can read what was said. See Project context. The agent reads meetings read-only. It never joins, records or changes them.

After a workshop, ask the agent for the requirements:

Write the requirements for order-to-cash from yesterday's Contoso workshop and the
follow-up emails. Name the source and the person for each requirement, and list the
open questions for the next workshop.

The agent writes the requirements per business process as an artifact in the project, with the source of each item. Open questions and conflicting statements become a list for the next workshop, or tasks for the client. Ask the agent to keep a decision log in the project, so later sessions and your colleagues reuse the decisions.

You decide which requirements are in scope, their priority, and when they go to the client for sign-off.

Solution design

Solution design turns the signed requirements into a design for the target system. Ask the agent for a fit-gap matrix. It marks each requirement as standard, configuration, extension or workaround, and saves the matrix as an Excel artifact.

The agent reads the client’s account through its connection, so the design matches the edition, the enabled features and the existing setup. Reads do not need approval. The agent then drafts the design document: structure, master data, processes, approvals and integrations. It flags the gaps that change scope or cost.

You decide how each gap is closed and which extensions or third-party apps the client buys. Share the design with the client through a link, and ask the agent for a sign-off form when the client must confirm it.

Configuration

Configuration builds the signed design in the target system. Give the agent the design and the sandbox connection, and ask for a configuration plan. Review the plan, then let the agent apply it. Before the first write, the agent asks once for the permissions the plan needs.

How the agent configures depends on the system:

• NetSuite: Custom fields, record types, forms, workflows and scripts deploy through SuiteCloud. See NetSuite configuration.
• Acumatica: Setup screens such as payment terms, numbering sequences, preferences, users and roles become available through a custom endpoint. See Acumatica configuration.
• Sage Intacct: Module preferences, dimension settings and terminology change through a ready-made tool that plans, applies and verifies each change. See Sage Intacct configuration.
• Other systems: The agent configures through the system’s API where the API exposes the setup.

Ask the agent for a configuration workbook that lists every setting it changed. After the client accepts the sandbox, repeat the same configuration in production with the production connection.

Testing and UAT

Testing shows that the configured system runs the client’s processes from end to end. Ask the agent to write test scripts per process from the requirements and the design. It saves them as an artifact in the project.

For system tests, the agent creates test transactions in the sandbox and records the result of each script. These are writes, so the agent asks for permission before the first one.

For UAT, ask the agent for a UAT tracker form. Share it with the client testers through a link. Their answers are visible to your team as they type. Ask the agent to add each defect as a project task that names the requirement and the setting it affects.

You decide which processes go through UAT, who tests them, and which defects block go-live. Ask for a sign-off form when the client signs off UAT.

Approvals, runs and playbooks

• Approvals: The agent reads source and target systems freely. Before it writes, updates or deletes data in a client system, it lists the permissions it needs once in plain language, such as “Create 1,240 vendors in NetSuite”, and waits for your approval.
• Runs: Loads and syncs run as saved tools with no AI at execution time, so the sandbox load and the production load apply the same transformation. Every run is recorded with its input, each step’s result and its output. See Monitoring runs.
• Playbooks: Duplicate a built-in playbook and adapt it to your firm’s method, so every consultant runs implementations the same way. See Playbooks.

Where to go next

Start with Project context. If you only want to try the agent on one system first, a Data assessment is a safe, read-only starting point.