Plotly.js to Dash migration boundary: can dcc.Graph and client-side charts coexist during a zero-downtime cutover?

Migration context

A small application currently renders interactive charts client-side with Plotly.js. The goal is to migrate to Python Dash, which wraps Plotly.js through its dcc.Graph component, without taking the application offline. The plan is a gradual rollout where some views are served by Dash callbacks while others still use the existing JavaScript rendering.

Constraints and uncertainty

Dash runs as a separate server process, so during the transition both rendering paths must be deployed and routed in parallel. Interactivity currently implemented in JavaScript (hover behavior, click events, zoom state) would move into Dash callbacks, and it is unclear which of those behaviors translate directly and which need reimplementation. State that previously lived in the browser would need a server-side equivalent. There is also a known risk of rendering inconsistencies when the Plotly.py/Dash version pair does not match the Plotly.js feature set the existing charts rely on; this should be verified against current release notes before rollout.

Open questions

• Is maintaining dual rendering paths (Plotly.js and Dash dcc.Graph) behind feature flags a sound approach for zero-downtime cutover, or does it introduce state-consistency problems between the two?
• Which Plotly.js client-side interactions are known not to map cleanly onto Dash callbacks and would need redesign?
• What version-compatibility checks between Plotly.py and Dash should gate each migration step?