AI Provider Migration Checklist

Use this checklist whenever you are switching one AI provider for another in a DAVE tenant. Common scenarios include:

• Switching AI service vendors. Moving from OpenAI to Anthropic, from Google AI to Azure OpenAI, or from any named provider to an OpenAI-compatible endpoint. The provider type changes, the base URI changes, and the model catalog needs to be rebuilt for the new service.

• Moving between environments within the same vendor. For example, migrating from a shared OpenAI API key to a dedicated Azure OpenAI deployment, or from an Anthropic development key to a production key with higher rate limits. The provider type may stay the same but the base URI and API key change.

• Rotating to a new API key on the same service. If you are only rotating the API key without changing the provider type or base URI, you do not need the full migration checklist: edit the provider record, paste the new key, click Fetch Models to verify, and save. Use this full checklist only when the endpoint or service is also changing.

• Adding a local or custom provider alongside an existing one. If you are adding a Local (Ollama) or Custom provider to run specific agents on a different endpoint while keeping existing agents on their current provider, use the new provider setup phase of this checklist and skip the agent re-pointing and cleanup phases for agents you are not moving.

This checklist assumes you hold the Admin role. Provider management is restricted to Admin users: only Admins can view, create, edit, or delete providers at Admin, then API Management, then Providers.

Complete every item in this phase before creating the new provider or touching any existing configuration.

1. Identify all agents using the provider you are replacing. Navigate to your agent list and note every agent that references the current provider. Record the agent name, the model it uses, and the workflows it appears in. This is your migration scope. Do not proceed until you have a complete list: an agent you miss will break when the old provider is removed.

2. Confirm the new provider's API key is ready. Obtain the API key for the new AI service before opening DAVE. For Azure OpenAI, also confirm your deployment name and endpoint URL. For OpenAI-Compatible or Custom providers, confirm the base URI and any authentication details required. Do not start the migration without these credentials in hand.

3. Check for running workflow instances. Check whether any workflow instances are currently running that use agents on the provider you are replacing. A running instance that calls an agent mid-execution will fail if the provider is deleted or its key is invalidated before the instance completes. Wait for running instances to finish, or pause them, before proceeding.

4. Confirm the new service's model availability. Verify that the models your agents currently use are available on the new provider. Model IDs differ across services: gpt-4o on OpenAI is not the same identifier as a GPT-4o deployment on Azure OpenAI, and Anthropic model IDs follow a different naming convention entirely. Identify the equivalent model on the new service for each agent in your migration scope before you begin.

5. Note the current provider's base URI and model catalog. Navigate to Admin, then API Management, then Providers and expand the current provider card by clicking the chevron. Record the base URI and the models currently in the catalog. This gives you a reference point if you need to roll back.

With the pre-migration audit complete, create and verify the new provider before touching any agent configuration.

1. Navigate to Admin, then API Management, then Providers. Click Add Provider in the top-right corner. The create form appears above the provider list.

2. Enter a descriptive name. Use a name that identifies the service, purpose, and environment clearly, for example "Anthropic Production" or "Azure OpenAI eastus2 gpt-4o". A clear name makes the provider immediately identifiable in agent configuration dropdowns and in the provider list.

3. Select the Provider Type. Choose from the seven supported types: OpenAI, Anthropic, Azure OpenAI, Google AI, OpenAI-Compatible, Local (Ollama), or Custom. Selecting a known type auto-fills the Base URI with the service's default endpoint. Default base URIs: OpenAI at https://api.openai.com/v1, Anthropic at https://api.anthropic.com/v1, Google AI at https://generativelanguage.googleapis.com/v1beta. For Azure OpenAI, OpenAI-Compatible, and Custom, you must supply the endpoint manually.

4. Enter or confirm the Base URI. For known provider types, verify the auto-filled URI is correct. For Azure OpenAI, enter your deployment-specific endpoint. For OpenAI-Compatible or Custom, enter the endpoint URL provided by your service.

5. Enter the API Key. Paste the API key into the masked field. Click the eye icon to verify it was pasted correctly before proceeding. The key is stored using AES-256-GCM authenticated encryption and is never returned through the API or displayed in plain text after saving.

6. Build the model catalog. For all provider types except Custom, click Fetch Models to retrieve the available model list from the service. A successful fetch confirms the API key and base URI are correct. Select only the models your agents will use. For Custom providers, switch to JSON mode and enter the model catalog manually as a JSON array, for example [{ "id": "my-model", "name": "My Model" }].

7. Verify the fetch succeeded before saving. If Fetch Models returns an error, stop and resolve the issue before saving the provider. Common causes: the API key is missing or incorrect, the base URI does not match the service's expected endpoint, or the service is temporarily unreachable. Do not save a provider whose connectivity is unverified.

8. Click Create Provider. The new provider card appears in the provider list. Expand it with the chevron to confirm the model catalog populated correctly.

With the new provider created and verified, update each agent in your migration scope to use the new provider and model.

1. Open each agent in your migration scope. For each agent identified in Phase 1, open the agent configuration. Locate the provider and model fields.

2. Switch the provider to the new record. In the provider dropdown, select the new provider you created in Phase 2. The model dropdown will update to show the models in the new provider's catalog.

3. Select the equivalent model. Choose the model on the new provider that corresponds to the model the agent was using on the old provider. Refer to the model equivalence notes you made during Phase 1. If the new service uses a different model ID for the same capability, select the correct one now.

4. Save the agent. Confirm the agent record saves without error.

5. Test the agent. Run a test workflow instance that exercises the re-pointed agent. Confirm the instance completes successfully and the agent's output is as expected. A successful test confirms the new provider's API key, base URI, and model are all working correctly for this agent.

6. Repeat for every agent in your migration scope. Do not delete the old provider until every agent has been re-pointed and tested. Deleting the old provider before all agents are updated will cause immediate failures for any agent still referencing it.

Once every agent in your migration scope has been re-pointed and tested, complete the cleanup phase.

1. Confirm no agents still reference the old provider. Review your agent list one final time. Check that no agent's provider dropdown still shows the old provider name. An agent that still references the old provider will fail when the old provider is deleted.

2. Check for running instances one more time. Before deleting the old provider, verify that no workflow instances are currently running that were started before the agent re-pointing was complete. Wait for any remaining instances to finish.

3. Delete the old provider. Navigate to Admin, then API Management, then Providers. Click the trash icon on the old provider card. The provider is removed immediately. This action cannot be undone: if you need to restore the provider, you will need to recreate it with the original API key and model catalog.

4. Verify the provider list. Confirm the old provider card no longer appears in the list. Confirm the new provider card is present and its model catalog is intact.

5. Run a final end-to-end test. Trigger a complete workflow run that exercises all agents that were migrated. Confirm every agent call succeeds and the workflow instance completes without error. This is your sign-off that the migration is complete.

6. Revoke the old API key at the source. Log in to the old AI service's management console and revoke or delete the API key that was stored in the old DAVE provider. A key that is no longer in use should not remain active. Revoking it closes the credential lifecycle cleanly.

Do I need to rebuild my workflows when I switch providers?
No. Workflows reference agents, and agents reference providers. When you update an agent to point to a new provider, every workflow that uses that agent picks up the change automatically. No workflow graph needs to be redrawn or reconfigured.

What happens to running workflow instances during a migration?
A running instance that calls an agent mid-execution will use the provider configuration that was active when the agent call was made. If the old provider is deleted before the instance completes, the next agent call in that instance will fail. Wait for running instances to finish before deleting the old provider.

Can I run two providers for the same AI service simultaneously?
Yes. DAVE supports multiple provider records for the same service type. You can have both an "OpenAI Staging" and an "OpenAI Production" provider active at the same time, with different agents pointing to each. This is useful for testing a new API key or model configuration before committing to a full migration.

What if the new service uses different model IDs?
Model IDs are service-specific. Use the Fetch Models function on the new provider to see the exact model IDs available, and match them to the capabilities your agents require. Update each agent's model selection individually during Phase 3.

Can I use a Local (Ollama) provider as the migration target?
Yes. Local (Ollama) is one of the seven supported provider types. The default base URI for a Local (Ollama) provider is http://localhost:11434/v1. Note that "local" refers to where the Ollama model server is running, not where DAVE is deployed: DAVE is fully managed and hosted by voolama LLC. The Ollama server must be reachable from DAVE's servers at the base URI you configure.

What if Fetch Models fails on the new provider?
Do not proceed with the migration until Fetch Models succeeds. Check the API key, verify the base URI matches the service's expected endpoint, and confirm the service is online. For Azure OpenAI, confirm that at least one model is deployed in your Azure resource. For Custom providers, Fetch Models is not available: use JSON mode to enter the model catalog manually.

Who can perform a provider migration?
Only users with the Admin role can view, create, edit, or delete providers. The Providers page at Admin, then API Management, then Providers is not accessible to any other role.