Learn when Flow Migrator emits native database actions and when SQL, MySQL, OLE DB, AS400, or Nintex Tables patterns still need review.
Database-backed workflows need connector-family decisions that are safe, predictable, and honest. These guides explain SQL Server, MySQL, OLE DB/ODBC, AS400-style queries, Nintex Tables, gateway dependencies, and the current limits.
Articles in this category
Browse all guides in Databases & connectors.
How SQL Server and MySQL actions are converted
See how Flow Migrator maps recognizable database CRUD patterns to SQL Server and MySQL Power Automate actions.
How OLE DB, ODBC, and AS400-style queries are handled
Understand why generic provider-based database actions are marked partial and how to choose a replacement target.
What to do with Nintex Tables during migration
Choose a replacement data store when workflows depend on Nintex Tables that cannot be converted one-for-one into Power Automate.
When to use the gateway troubleshooting guides
Use Flow Migrator's gateway guides before importing flows that depend on on-premises SQL Server, MySQL, PostgreSQL, Oracle, SharePoint, or file-system data.
When DB2 actions are native vs manual review
Simple DB2 row and table patterns can map cleanly to native DB2 actions, while complex joins and vendor-specific queries still deserve manual review.
How Flow Migrator chooses SQL Server, DB2, and IBM i routes
Database connector routing should follow the actual provider and integration style, not just the platform nickname people use internally.
Why complex FRN queries stay manual review
When a workflow depends on joined, aggregated, or vendor-specific database queries, the honest output is often partial or manual review rather than a fake native action.