Hi everyone, We are currently planning a major upg...
# replication-troubleshooting
t
Hi everyone, We are currently planning a major upgrade of our self-hosted Airbyte instance, migrating from version
0.59.1
to
2.3.0
. We rely heavily on the Declarative CDK and have dozens of custom connectors. Because of this scale, recreating each of them manually from scratch via the Connector Builder UI is completely unfeasible for our team. Initially, we tried the straightforward approach: exporting the YAML manifest from the obsolete version and importing it directly into the new version's Connector Builder. However, this approach throws validation errors and fails to save the draft. Since a simple UI import doesn't work for these legacy manifests, we are looking for suggestions on how to best handle this transition. What is the officially recommended approach to migrate and deploy these legacy YAML manifests into v2.3.0? Any guidance or documentation you could share would be hugely appreciated! Thanks in advance.
a
I would probably build a new instance side by side and tried to move connectors one by one testing connector first, import - probably if go direct into python without UI problem will be trivial - some changes in the markup and yaml fileds, but haven’t done it myself
j
@tarcisio.pacheco We haven't had many issues moving old manifests over, and we've been working with declarative connectors since they were added. I'm curious what types of errors you're seeing and where they show up in the process. Also, and I know this is silly—but pass it to an LLM with the context you provided here and the error details and see if it can identify the change and fix it (I'd be pretty shocked if it can't). If that works, let it do the same for all of them. Might just be faster to solve for this, and if that works you can make a second pass and ask it to modernize/improve the connector with features that didn't exist at the time you created the original (e.g. parallelization).
👍 1