MySQL / ODBC Developer Needed to Rebuild Small Windows-to-Ubuntu Database Bridge

We are looking for an experienced database/integration developer to recreate a small legacy data bridge between a Windows PC connected to our manufacturing ERP through ODBC and an existing Ubuntu/MySQL/PHP application. This is not a full application rebuild. The existing Ubuntu application is operational. We need to replace a missing Windows-side extraction/bridge process that previously transferred sales order data into two MySQL staging tables. Current Environment Source Windows PC Proprietary manufacturing/ERP system Transoft ODBC / MC Connect interface Working ODBC DSN already configured We have successfully queried live ERP data through Excel/Microsoft Query Destination Ubuntu server MySQL 5.5 Existing PHP application Existing MySQL staging tables: none_SOHEAD none_SOLINE The existing Ubuntu application reads those staging tables and handles the downstream production-order processing. What We Have Already Confirmed We can successfully query both source ERP tables through ODBC: SOHEAD — sales order headers SOLINE — sales order line items We tested a current sales order and successfully retrieved the correct SOHEAD record and all six corresponding SOLINE records. The source MCMS fields correspond directly with the fields expected by the Ubuntu application, so there does not appear to be significant data transformation required. Existing Ubuntu Processing Logic The existing PHP application selects recent SOHEAD records using logic equivalent to: SELECT sonum, entdt FROM none_SOHEAD WHERE ordtyp != 'C' ORDER BY entdt DESC; For each relevant sales order it then reads: SELECT * FROM none_SOLINE WHERE sonum = 'SO_NUMBER' AND partkey != 'IVD'; and the corresponding SOHEAD record. The existing PHP application then determines whether each production-order line should be inserted or updated in its production tables. Required Source Data SOHEAD fields include: sonum, cntact, cust, entdt, invdt, invnum, pocust, prmdt, stadd1, stadd2, stcity, stname, stst, stzip, ucom4, ucom5, usrnam, whse, ordtyp SOLINE fields include: sonum, descr, dim1, lnnum, ordins, ordlbs, ordqty, partkey, recnum_soline, totprc Legacy Process The previous system used PHP processes hosted on an old Windows 7 PC. The Ubuntu server periodically called: order_proc.php order_proc_full.php on that Windows PC. After those calls, Ubuntu ran its existing local ord_process.php, which reads none_SOHEAD and none_SOLINE. The original Windows PHP files are no longer available. Based on the existing application and cron history, the old Windows process appears to have: Queried the ERP database through ODBC. Populated/refreshed Ubuntu MySQL none_SOHEAD and none_SOLINE. Allowed the existing Ubuntu PHP process to process those staging records. What We Need Built We need a reliable replacement bridge running on the new Windows PC that: Connects to the existing working ODBC DSN. Queries the appropriate SOHEAD and SOLINE records. Transfers the data securely to the Ubuntu/MySQL staging tables. Safely populates or refreshes none_SOHEAD and none_SOLINE. Prevents duplicate or partially imported records. Preserves compatibility with the existing Ubuntu PHP application. Includes useful logging and error reporting. Can run automatically on a schedule. Supports an appropriate recent-order synchronization and, if needed, a longer periodic refresh. Includes source code and documentation so another developer can maintain it in the future. Python, PHP, or another appropriate Windows-compatible solution is acceptable. We are open to your recommendation for the simplest and most reliable architecture. Safety / Testing Requirements This system is used in production, so implementation must be conservative. We want the developer to: Review the existing environment before making changes. Back up relevant MySQL data before production testing. Initially test using a known sales order. Verify staging-table data before enabling automatic processing. Avoid changing the existing ConFab Connect application unless absolutely necessary. Provide a rollback plan. Provide source code and simple written documentation. Ideal Experience Strong experience with: MySQL SQL ODBC Python and/or PHP Windows-to-Linux integration ETL / database synchronization Ubuntu/Linux Scheduled/background processes Legacy PHP/MySQL applications Database backup and rollback procedures Please Answer These Questions in Your Proposal Have you built an ODBC-to-MySQL or similar database synchronization bridge before? Please briefly describe one. Based on the environment described above, what architecture would you recommend? Would you use Python, PHP, Access/VBA, or another method, and why? How would you safely refresh the two staging tables without causing duplicates or exposing the system to partially imported data? What would happen if the synchronization fails halfway through a run, and how would you recover? How would you provide logging so we can see the last successful synchronization and what records were processed? Approximately how long do you expect the initial build and testing to take? Are you available to begin immediately? Are you able to overlap with Pacific Time business hours when live access/testing is required? Please begin your proposal with ODBC BRIDGE so we know you reviewed the complete project description. We can provide additional technical details, screenshots, table structures, existing PHP code excerpts, cron history, and access information privately to the selected developer.