You have budgeted for a website redesign. You have written the RFP. You have selected the vendor. The project kicks off and everything is moving forward. Then, four weeks in, your development partner delivers the news: reconnecting your existing integrations is going to add six to eight weeks and $25,000 to $40,000 to the project.
This happens to associations constantly. It happens because integrations are invisible infrastructure. They work quietly in the background, moving data between systems, authenticating members, syncing events, and processing transactions. Nobody thinks about them until the redesign forces a reckoning with every connection your website has to the outside world.
Here is what actually happens to your integrations during a redesign and how to plan for it so the budget shock does not derail your project.
Why Integrations Complicate Redesigns
A website redesign changes the technology layer that your integrations are built on. If you are changing CMS platforms (WordPress to Drupal, or vice versa), every integration needs to be rebuilt from scratch because the underlying code, hooks, APIs, and data structures are completely different. If you are staying on the same platform but upgrading to a new major version, integrations need to be tested and potentially updated for compatibility. Even if you are just changing themes or restructuring the front end, integrations that touch the front end (member login forms, event calendars, payment processing pages) need to be verified.
The scope of the integration work depends on three factors: how many integrations you have, how tightly coupled they are to the current platform, and how well documented they are.
The Four Categories of Integration Migration
During a redesign, each integration falls into one of four categories:
Drop-in compatible. The integration is handled by a plugin or module that exists on both the old and new platform. Your Mailchimp integration on WordPress uses a plugin. Your new Drupal site has a contributed module that does the same thing. You install the module, configure it with your API key, and the integration works. Effort: 2 to 4 hours per integration.
Rebuildable. The integration uses the external system is API, so the API connection works regardless of your CMS. But the code that lives on your website, the part that calls the API, processes the response, and displays the data, needs to be rewritten for the new platform. The business logic stays the same. The implementation changes. Effort: 8 to 40 hours per integration depending on complexity.
Deprecated. The integration relied on a tool, plugin, or approach that does not exist on the new platform and has no equivalent. Maybe your current site uses a WordPress plugin that has no Drupal counterpart. Maybe the integration was built on a deprecated API version that the external vendor no longer supports. The redesign forces you to find a new approach or drop the integration entirely. Effort: highly variable, from 0 (if you drop it) to 40+ hours (if you need a new solution).
Undocumented. Nobody knows exactly what this integration does, how it was built, or what credentials it uses. The original developer is gone. There is no documentation. The code has no comments. Before you can migrate it, you have to reverse-engineer it. This is the most expensive category and the most common one in associations that have accumulated integrations over multiple website generations. Effort: 16 to 80 hours per integration to understand and rebuild.
The Budget Impact
Here is the math that catches associations off guard. Assume you have eight integrations:
- 2 drop-in compatible: 8 hours total
- 3 rebuildable: 60 hours total
- 1 deprecated: 20 hours total
- 2 undocumented: 80 hours total
That is 168 hours of integration work at $150 per hour: $25,200 in integration costs on top of the redesign itself. For an association that budgeted $80,000 for the redesign expecting that integrations were "already done," this is a 31 percent budget overrun.
Some associations have twelve or fifteen integrations. The integration cost can exceed the design and development cost of the new website itself.
What to Put in Your RFP
The easiest way to avoid this surprise is to address integrations explicitly in your RFP. Include a complete list of every external system your website connects to, with a description of what each integration does, how it was built (plugin, custom code, middleware), and what credentials or accounts are involved.
Ask vendors to provide separate line items for integration migration. Do not let them bury integration work in a general "development" line item. You need to see exactly how much of your budget goes to reconnecting existing functionality versus building new features. If you are starting the document from scratch, our guide to writing a website redesign RFP covers the rest.
Ask vendors to classify each integration into the four categories described above. Their classification tells you how well they understand the scope and where the risk concentrates.
Include a discovery phase in the project timeline specifically for integration assessment. Before any development begins, the vendor should review every integration, document its current implementation, and provide a detailed migration plan. This discovery typically costs $2,000 to $5,000 but can save $20,000 or more by identifying undocumented or deprecated integrations before they become mid-project surprises.
The Redesign as Integration Audit
A website redesign is actually the best time to rationalize your integration stack. You are already rebuilding. The incremental cost of dropping an integration you do not need is zero, while the cost of migrating it is real.
For every integration, ask: if this integration did not exist today, would we build it for the new site? If the answer is no, do not migrate it. Let the redesign be the clean break.
Some integrations were built for a tool you no longer use. Some were workarounds for limitations in your old platform that the new platform handles natively. Some connected to a vendor you have since replaced. A redesign is your opportunity to start with a clean, intentional integration stack rather than carrying forward every connection that accumulated over the past five years.
Planning for Integration Success
Here is the process that prevents integration surprises during a redesign:
- Before the RFP: Inventory every integration. Document what it does, how it works, and who maintains it. Include this inventory in the RFP.
- During vendor selection: Ask each vendor how they handle integration migration. Their answer tells you whether they have done this before.
- During discovery: Have the selected vendor assess each integration and classify it. Get a fixed-scope estimate for migration work.
- During development: Test integrations early, not at the end. Integration issues discovered in week two are cheaper to fix than integration issues discovered in week twelve.
- Before launch: Run the old and new sites in parallel for a period to verify that all integrations produce the same results. Do not cut over until data flows are confirmed.
Integrations are the part of a redesign that most associations underestimate and most RFPs underspecify. Address them early, budget for them honestly, and use the redesign as an opportunity to clean up your stack. Your next website will be simpler, more maintainable, and less expensive to operate.