Choosing an AWS partner for Bedrock migration: From assessment to production
Moving an AI application to Amazon Bedrock takes more than changing its endpoint. Learn what to look for in an AWS migration partner, from OpenAI and Gemini compatibility testing to security, operating costs, cutover, and handover.
- Treat the migration assessment as a starting point, then validate its findings against production usage.
- Choose a migration path for each workload based on compatibility, quality, and operating requirements.
- Test tools, streaming, conversation state, retries, and failure handling before accepting API compatibility.
- When changing embedding models, regenerate affected embeddings and validate retrieval before switching traffic.
- Compare cost per successful task, including infrastructure, retries, review effort, and transition costs.
- Require evidence that permissions, network access, logging, retention, and processing locations meet your requirements.
- Select a partner with clear deliverables, acceptance criteria, and ownership. Rehearse cutover, rollback, and customer handover.
An assessment can identify the models your application uses, recommend Bedrock alternatives, and estimate the work involved. Your team still needs evidence that the migrated application answers correctly, executes tools safely, and meets its operating requirements.
That is the responsibility to examine when choosing an AWS partner for Bedrock migration. The partner should explain what will change, how those changes will be tested, and who will own the application after cutover.
A capable internal team can execute this work. Outside support adds value when it closes specific engineering or operational gaps and provides deliverables your team can inspect and accept.
This guide covers moving existing OpenAI and Gemini application workloads to Amazon Bedrock. Depending on the workload, that can mean changing the inference provider and integration, adopting a different model, or moving selected functions while retaining others with their current provider.
What happens after an AWS Transform Bedrock migration assessment?
AWS currently lists AWS/GenAI-to-Bedrock-Migration-Assessment as an early-access, assessment-only transformation. It discovers model and SDK usage, clarifies requirements, maps models, estimates cost and risk, and generates assessment artifacts. It does not modify application source code.
AWS describes five phases: discover, clarify, map, estimate, and recommend. Outputs include model mappings, cost estimates, an SDK migration guide, and a migration runbook. These give the implementation team a structured starting point.
This scope applies to the specific Bedrock assessment transformation. Other AWS Transform workflows have different capabilities.
Before implementation begins, reconcile the assessment with production usage. Model selection may also live in runtime configuration, a shared gateway, or services outside the scanned repositories. Ask the delivery team to validate the inventory against deployment settings and operational evidence.
The first deliverable should be an agreed workload list with dependencies, migration decisions, unresolved questions, and owners. That makes it possible to estimate implementation work without treating repository discovery as proof of completeness.
Choose the migration path per workload
An application may use one model for extraction, another for search, and a third for a live interaction. Those functions can have different migration requirements.
A recommendation should explain why each workload follows its chosen path. Moving everything at once may create unnecessary dependencies. Keeping multiple providers also carries ongoing operating costs and responsibilities.
For example, an illustrative support application could move document summarization first while retaining a specialized interaction elsewhere. The proposal should identify what that separation achieves and how the team will operate it.
OpenAI to Amazon Bedrock migration
Supported OpenAI models are available on AWS-managed infrastructure through the Bedrock Runtime (bedrock-runtime) and Mantle (bedrock-mantle) endpoints. Availability depends on the model, API, and AWS Region. OpenAI-compatible APIs can allow continued SDK use, but feature coverage differs by endpoint. Function calling, structured outputs, and streaming are supported capabilities; compatibility still needs checking against the application's exact usage. Function calling produces requests for tools; the application remains responsible for authorizing and executing those operations.
Use the current OpenAI on Amazon Bedrock documentation to verify dependencies. A working text-generation request does not establish compatibility for hosted tools, conversation state, or every response-handling path.
Ask the implementation team to distinguish configuration changes from necessary code changes. Rewriting every tool integration without testing compatibility can inflate scope. Assuming SDK compatibility removes all migration work can leave necessary changes undiscovered.
Gemini to Amazon Bedrock migration
For Gemini workloads, require a proposed target model and an explanation of how it meets the current task requirements. Assess instruction following, output structure, multimodal inputs, tool behavior, safety responses, and operational limits separately.
A model mapping is a candidate to evaluate. Test representative requests, difficult examples, and failure cases before accepting it. Record any change in user-visible behavior and the work needed to accommodate it.
If only some functions meet the acceptance criteria, partial migration remains an option. Define the retained services and ownership explicitly rather than leaving them as temporary exceptions without an operating plan.
Turn compatibility findings into implementation tasks
A useful compatibility matrix connects each dependency to a tested target and a named change. It should cover API and SDK versions, model identifiers, endpoints, Regions, tool schemas, streaming, state management, retries, timeouts, and quotas.
Tool execution deserves particular attention. Test whether arguments satisfy the application's requirements, whether malformed responses are handled, and what happens after timeouts or retries. For operations that change business records, verify that a repeated request does not cause an unintended duplicate action.
Assess application-managed and provider-managed state separately from the model request. Establish where conversation history is stored, how sessions resume, and what information must survive a deployment or provider switch.
Request reviewed application and infrastructure changes, integration tests, and documented exceptions. The scope should make clear which findings are resolved, which require redesign, and which remain outside the migration.
Scope embedding and retrieval changes carefully
An embedding migration needs its own evaluation. Matching input formats or vector dimensions does not establish that vectors from different models are compatible or that retrieval will behave the same way.
Gemini Embedding 2 supports text, images, video, audio, and PDFs in a unified embedding space. Amazon Nova Multimodal Embeddings also supports text, documents, images, video, and audio in a unified semantic space. Comparing Gemini only with Titan would miss a relevant Bedrock option.
Evaluate actual input limits, segmentation, preprocessing, retrieval quality, throughput, and cost for the corpus involved. A product's modality list cannot answer those questions on its own.
When changing embedding models, plan to regenerate the affected embeddings and validate retrieval in a separate index before switching traffic. Keep document identifiers, source material, and useful metadata where the target design permits. Use compatible document and query embeddings for each index. The affected collections determine the scope; unrelated vector stores may remain unchanged.
The partner's retrieval plan should specify how new content is indexed during transition, which queries are used for comparison, and how the application returns to the previous retrieval configuration if needed.
Plan your move to Amazon Bedrock
Compare cost per successful task
OpenAI states that Bedrock pricing in commercial Regions matches direct OpenAI pricing for equivalent services, with regional-processing qualifications. AWS commercial terms apply. This is a qualified rate comparison, rather than a guarantee of unchanged application cost.
Evaluate the complete workload: input and output consumption, retries, caching, tool charges, embeddings, storage, networking, logging, and supporting infrastructure. Include migration engineering and the period when both environments operate.
Measure cost per successful task alongside quality and latency. Define the measure as total workload cost over a stated period divided by the number of tasks meeting the agreed acceptance criteria. For a document-extraction workflow, count outputs meeting the agreed field-level requirements and include review or correction effort in the cost calculation. A cheaper response that requires more repair may increase the cost of completing the work.
Ask for the assumptions behind estimates, including traffic mix, concurrency, model choice, and deployment option. Separate measured benchmarks from projections. Verify credits, discounts, and spend-commitment treatment against customer-specific terms.
Treat assessment estimates as planning inputs and validate them with representative workload measurements before making a commercial commitment.
Require security evidence for the selected deployment
A migration creates an opportunity to improve controls. Those controls still need configuration and testing for the chosen model, endpoint, and routing path.
Private access and permissions
AWS documents PrivateLink connections for Bedrock, including Mantle. Establishing private access requires interface endpoints and appropriate DNS, network, and endpoint-policy configuration. Changing a model endpoint alone does not configure the private path.
Ask the delivery team to demonstrate the intended network route and test denied access. Review execution roles and credential handling, including which workloads can invoke the selected services.
Audit activity and invocation content
CloudTrail records API activity; model invocation logging can capture supported request and response content for investigation. CloudTrail coverage and configuration depend on the operation and endpoint; some data events require explicit enablement.
Model invocation logging can collect supported request and response content in CloudWatch Logs or S3, but it is disabled by default. Current documentation limits this feature to Bedrock Runtime, including its OpenAI-compatible APIs. Calls through Mantle are not currently captured by it.
Require evidence that the chosen deployment produces the records needed for investigation. For Mantle, specify how any required invocation-content evidence will be captured through approved application or gateway logging. Protect customer content recorded in logs and set appropriate retention.
Retention and processing location
Review the selected model's retention requirements and the effective account or project configuration in each relevant Region. AWS documents that a zero-retention setting can block a request if the chosen model requires retention; this can affect model availability as well as data handling. “Not used for training” does not establish that content is never retained. AWS also documents destination-Region storage of retained inputs and outputs for applicable cross-Region inference.
Use the Bedrock data-retention documentation to examine the intended configuration. Include inference routing and customer-managed logs in the review so the endpoint's Region is not treated as the complete residency answer.
How to evaluate an Amazon Bedrock migration partner
The most useful comparison is what each provider commits to deliver and how you will accept it. Use the following framework when reviewing Amazon Bedrock migration services proposals.
Ask prospective partners to describe comparable work, their evaluation method, and the people responsible for delivery. Request evidence they are authorized to share, including the target models, endpoint choices, test approach, and operational outcomes where available. General AWS credentials help assess background; application-level migration evidence addresses the specific assignment.
Agree acceptance criteria with your business and engineering owners. A universal accuracy percentage or latency target cannot substitute for the requirements of the application being moved.
Rehearse cutover, rollback, and handover
Before cutover, establish a controlled deployment sequence, monitoring, stop conditions, and a rollback decision-maker. Test representative concurrency and failure conditions in a suitable environment before exposing users to changes. Confirm model access, quotas, and source-model retirement dates before setting the cutover schedule.
If using shadow traffic, ensure it cannot repeat consequential actions or send data to an unapproved destination. If introducing limited live traffic, define which requests qualify and how results are reviewed.
Rollback should address model routing, application configuration, retrieval indexes, and state. Returning to the old endpoint may not undo a record update or recover conversation state created in a different system. Document how those cases are handled.
Handover should demonstrate that the customer team can diagnose a failed request, interpret costs, adjust configuration, and release a change. Assign ongoing responsibility for model lifecycle changes, incidents, billing, and optimization before project closure.
Define the implementation scope with Applify
Applify's AWS services include cloud migration, modernization, and generative AI. For a Bedrock migration discussion, bring the assessment, current architecture, integration inventory, and representative evaluation examples.
Use those inputs to agree the proposed migration path, required engineering changes, acceptance evidence, and operational responsibilities. Specific delivery scope should follow the workload review.
Explore Applify's AWS capabilities to discuss the work between assessment and production. The starting decision is which workload to move first and what evidence your team needs before approving cutover.
