This comprehensive guide provides a systematic approach to migrating behavioral data sources while maintaining model performance and data integrity. The process ensures seamless transition from legacy integrations to new data sources without disrupting ongoing sales operations or model accuracy.
The methodology outlined here emphasizes careful validation, performance comparison, and rollback capabilities to ensure business continuity throughout the migration process.
Prerequisites - Week 1
Critical requirement: MadKudu technical team involvement is mandatory for batch processing steps
Plan accordingly to MadKudu's availability for this project
Identify the current behavioral data source and the target migration source
Confirm which behavioral integrations are currently connected
Assess the scope of migration (lead-level, account-level, or both)
Verify technical requirements and access permissions for the new data source
Data Source Setup - Week 1
Establish the new connection
Analysis - Week 2
Compare the volume of records per event per person and per month during the past 9 months
Extract historical data from both old and new sources
Analyze data volume consistency between sources
Identify any discrepancies in event tracking or data collection
Continue the migration process only if volume differences are acceptable
Migration Preparation - Week 3
Duplicate the event mapping, but put it on 'off'
Set the duplicated mapping to 'off' status to prevent immediate activation
Verify all event definitions and parameters are correctly copied
Duplicate the behavioral models
Create copies of all active behavioral models (Lead level and/or account level)
Label duplicated models clearly for migration tracking
Critical Migration Steps - Week 3
Stop the batch - ⚠️ Important: This step can be performed by MadKudu only
Ensure all current data processing is completed before stopping
Halt batch processing
Document the exact time of batch cessation for rollback purposes
Switch event mappings
Turn on the new event mapping configuration
Turn off the old event mapping
Load new datasets for draft behavioral models
Validate that all expected events from the new event mapping were properly loaded
Assign the same weights and lifespan for each event that matches the same event from the old integration
Compare the performance of the old model vs the new
Pay close attention to the Sample page, review with a pair
If performance is NOT similar:
Turn the original event mapping back on
Turn off the new event mapping
Re-enable batch processing
If performance IS similar:
Publish the new behavioral model(s)
Re-enable batch processing
Monitor the performance closely during the initial production period
Post-Migration Monitoring - Week 3&4
Monitor model performance for at least one week post-migration
Gather feedback from sales teams on any observable changes
Maintain ability to quickly revert to original configuration for 30 days
Keep original event mappings and models in archive state
Estimated time: 20 hours