Deep dive into the SSMA Code Conversion Copilot Architecture
The Problem We Set Out to Solve Migrating from Oracle PL/SQL to SQL Server T‑SQL is notoriously complex. While SSMA’s rule engine covers hundreds of conversion rules, edge cases, custom logic, and nuanced syntax but it often slips through. Developers end up spending hours manually fixing scripts, validating correctness, and worrying about regressions. The Copilot was built to tackle this pain point: augment SSMA’s rule engine with large language models (LLMs) that can reason about tricky conversions, explain their logic, and accelerate the migration process. But building trust in AI‑generated code meant we had to design an architecture that was controllable, reliable, and secure. SSMA Code Conversion Copilot was released back in the month of May and some of the use cases are elaborated here. This blog talks about the inner working of Copilot. ⚙️ Semantic Kernel for Skill / Plugin Management At the heart of SSMA Copilot lies Semantic Kernel, Microsoft’s open‑source framework for integrating LLMs. It offers two big capabilities: Prompt management — defining prompts as reusable “skills” with parameters like model, temperature, and token count. Agentic orchestration — automating workflows by chaining tools and prompts together. For Copilot, we deliberately chose only prompt management at this point. We have also added native skills such as checking the correctness of syntax and semantics but have not used agentic orchestration for the current implementation. ❌ Why Not Agentic Features? Agentic orchestration can be powerful, but in practice it wasn’t reliable enough for production migrations. Tool selection logic sometimes failed, leading to incorrect validations or spurious edits. Moreover, we saw an issue with latency. Instead, we implemented a deterministic workflow that gave us full control. ✅ Manual Orchestration Workflow Our workflow looks like this (please refer to the diagram): Partial Migration: SSMA generates a baseline conversion. Copilot Authentication: The Copilot is authenticated using the inputs provided by the user. This is where the model is also decided. Alternately, the user can use the managed endpoint that is controlled by Microsoft. LLM Completion: Copilot fills in gaps. Moreover, it explains the solution, points out the error that it is trying to resolve in simple language. Parsing & Compilation: A target‑dialect parser checks syntax. This catches unsupported constructs or binding issues far more reliably than prompt tuning. Spurious Edit Detection: LLMs are instructed to only enhance flagged portions of code. Any edits to “correct” blocks incur penalties, with a strict threshold of zero spurious edits allowed. Query Execution & Data Generation: Where possible, we generate minimal synthetic data (two rows per table) to validate equivalence between source and target queries. Semantic Equivalence Checks: For cases where execution isn’t feasible, we use LLM‑based scoring to judge logical fidelity. This loop repeats until syntactic and semantic correctness is achieved. By using this workflow, we avoided regression spirals and ensured predictable outcomes across dialects. This workflow was tested using our built-in evaluation framework which has leveraged the rich test cases of SSMA. 🔑 Feature Comparison Managed Endpoint Authentication was released with SSMA 10.4 in November 2025. Managed Endpoint BYOK Provisioning OpenAI Endpoint No Yes LLM Model Selection Automatic Manual Authentication Mandatory Entra ID OpenAI Endpoint and Key Private Endpoint Support No Yes Cross Tenant Dependency* Yes No Pricing Free Consumption in actuals *Cross Tenant Dependency: The endpoint is hosted in Microsoft tenant while the authentication happens in the user tenant. 🔒 Privacy and Data Handling A critical point: we don’t store your data. The scripts you provide are used only for generating the migration output. Once the process completes, the data is flushed. No proprietary code or schema information is retained. This design ensures: Security: We run OpenAI in Microsoft tenant following all security protocols. Trust: Copilot is a tool, not a repository. Compliance: Aligns with enterprise privacy expectations. 🌟 Why This Matters By combining Semantic Kernel framework, SSMA Copilot delivers reliable migrations without sacrificing flexibility. And with the managed endpoint, it’s now easier and safer than ever to adopt — no keys, no storage, no friction. This isn’t just about faster migrations. It’s about building trust in AI‑assisted workflows, ensuring correctness, and giving enterprises confidence that their data is secure. Get started with your Copilot based migration journey using SSMA for Oracle
Tenant to tenant mail migration from large to small organization
According to Microsoft sales team the answer in https://answers.microsoft.com/en-us/msoffice/forum/all/migrating-email-from-one-office365-account-to/da67871d-10b3-40d3-9108-cbd0a020c917 is most likely wrong! Can you confirm that? (commenting is not possible anymore) We are a small group in a very large organization now established as an independent company. A very common situation. New licenses for Office365 including everything and all premium have been acquired for our small independent group. The very reason to continue using Office365 is to ensure a smooth migration of Outlook mail including calendar, and only spending a minimum of time on related tasks. MS sales team advice that you can do a migration as in https://learn.microsoft.com/en-us/microsoft-365/enterprise/cross-tenant-mailbox-migration?view=o365-worldwide, but you require "Cross Tenant User Data Migration", which only is available to "Enterprise Agreement" customers - and of course not for our small group. How can we quickly and smoothly do the migration? In case of a work-around like exporting data to a PST-file, then please observe that this task must be completed in the web app, and we cannot achieve admin privileges in the large organization. The question has been migrated from https://answers.microsoft.com/en-us/thread/updatethread?forum=msoffice&threadId=01afb132-ad73-413b-b1ac-6439e24374e8&editType=EditThreadByOwner&messageId=00000000-0000-0000-0000-000000000000.
365 Tenant To Tenant Migration
I have a tenant who is not set up to be GCC compliant. We have created another tenant that is now GCC compliant and need to move the tenants from the original tenant to the newly created GCC compliant tenancy. I am not sure how we can go about doing this with the destination and origination having the same domain name. I have created the users with the onmicrosoft accounts, instead of the .org users, but we still have the issue of migration. How do we move these users? What is the expected down time for their domain if we use a dummy domain? I am very concerned this is going to result in a massive loss of data.Teams Delivers a Slack Migration Tool
Microsoft announced the availability of a Slack to Teams migration tool in the Microsoft 365 admin center. The new tool exists to assist the 79 million monthly active users of Slack who might want to move to Teams and don’t know how to get there. ISVs have been helping people move off Slack to Teams for years, so other migration options exist. https://office365itpros.com/2026/01/07/slack-to-teams-migration/
GoDaddy to Microsoft 365 Migration Issues
Hi there, I wonder if I could get some help with an issue I've got. Currently I am attempting to migrate one user mailbox from the current GoDaddy tenant to our new Microsoft tenant, to initially test out the migration. I've followed the Migration tool in the Exchange admin center but am receiving the following error: Error: MigrationRecipientNotFoundException: A recipient wasn't found for "***@***.onmicrosoft.com". Create a recipient of the appropriate type for this migration and try again. I've got the user created in the Microsoft 365 admin center and a mailbox is set up for them. Both on GoDaddy and Microsoft it is UserMailbox recipient type. I'm using the IMAP Migration settings as outlined from the GoDaddy IMAP settings, and have since checked with GoDaddy and they give these settings: IMAP Server: imap.secureserver.net Authentication: Basic Encryption: SSL Accept untrusted certificates: Yes Port: 993 GoDaddy have also said that Basic authentication is supported by them and I have checked the Entra configuration to ensure that Basic is not blocked. I have even had the user I'm attempting to migrate log in to the temporary onmicrosoft account to make sure there are no log in issues there. I have posted this on the Answers forum as well and was pointed in this direction for further help. Any thoughts or help on this would be amazing. Thanks in advance, Oli
