Migration factory offer
Bluefly Migration Factory
Turn a Complex Legacy Estate Into a Proven, Executable Migration System
Commercial Offer Definition — Draft for Forum One / Acquia / Strategic Partners Bluefly.io — September 19, 2026
The Problem
Large migrations rarely fail because teams cannot write migration scripts.
They fail because the source estate is poorly understood, the target architecture is still changing, hundreds of legacy components are treated as unique, validation is inconsistent, exceptions are discovered too late, and senior engineers repeatedly make the same decisions by hand.
At the scale of a large government or enterprise estate, that becomes expensive quickly.
A migration involving hundreds of legacy components and tens of thousands of pages cannot be managed as hundreds of independent engineering tasks.
It needs a production system.
The Bluefly Migration Factory
Bluefly's Migration Factory turns a complex, poorly understood legacy estate into a smaller number of known, executable migration patterns.
Instead of asking engineers to rediscover the solution for every component, Bluefly:
inventories and classifies the source estate;
defines the target Drupal architecture;
groups legacy components into migration families;
builds reusable migration patterns for representative families;
implements real migration code for those patterns;
validates migrated results automatically;
routes genuine exceptions to senior engineers;
captures new solutions back into the pattern library; and
leaves the implementation team with an executable migration backlog and operating model.
The result is not simply a discovery report.
The result is a proven migration system that an implementation team can run and extend.
What the Customer Receives
- Classified Legacy Estate
Bluefly creates an evidence-backed model of the source environment.
This includes, where applicable:
legacy templates and application components;
content and presentation structures;
database schemas and relationships;
custom business logic;
APIs and external consumers;
integrations and third-party systems;
mobile application dependencies;
media and document structures;
URL and redirect behavior;
authentication and authorization dependencies;
deployment constraints; and
known technical debt and migration risks.
The goal is not merely to count components.
The goal is to determine:
Which things are actually unique, and which things are variations of the same underlying migration problem?
That distinction is what creates leverage.
- Drupal Target Architecture
Bluefly defines enough of the Drupal 11 target architecture that implementation teams do not need to repeatedly reopen foundational decisions.
Typical decisions include:
content and entity models;
taxonomy and classification;
media architecture;
reusable component patterns;
custom-module boundaries;
API contracts;
integration boundaries;
decoupled/headless interfaces;
authentication and authorization;
configuration management;
caching and performance requirements;
deployment conventions;
rollback expectations; and
migration-specific engineering standards.
The architecture becomes the destination against which migration patterns are built and validated.
- Migration Family Model
The core of the Factory is the migration family.
Rather than treating 800 legacy components as 800 unrelated problems, Bluefly looks for groups that share:
source structure;
target structure;
transformation rules;
validation requirements; and
exception behavior.
For example:
800 LEGACY COMPONENTS
↓ classify
30 MIGRATION FAMILIES
↓ prove reusable patterns
KNOWN PATTERNS + EXCEPTION QUEUES
↓ execute repeatedly
MIGRATION WAVES
The exact number of families is discovered from the estate. The point is structural:
hundreds of implementation decisions become a much smaller number of reusable engineering patterns.
What a Migration Pattern Actually Contains
A migration pattern is not a slide or a paragraph in an architecture document.
It is an executable unit of engineering knowledge.
A completed pattern can include:
SOURCE DEFINITION → TARGET DEFINITION → FIELD / ENTITY MAPPING → TRANSFORMATION RULES → MIGRATION CODE → VALIDATION RULES → KNOWN EXCEPTIONS → HUMAN DECISION POINTS → ACCEPTANCE CRITERIA → EVIDENCE
Depending on the problem, implementation assets can include:
Drupal Migrate source plugins;
migration configuration;
process plugins;
transformation functions;
source queries;
API adapters;
test fixtures;
validation scripts;
CI/CD checks;
regression tests;
content comparison tooling;
evidence reports; and
reusable runbooks.
The customer receives working implementation assets for representative migration families, not merely recommendations about how those assets should someday be created.
Concrete Example: Legacy Park Alert
Assume the legacy estate contains a ColdFusion-based Park Alert capability used to publish closures, emergency notices, or operational updates.
The legacy implementation may include:
records stored in MSSQL;
ColdFusion templates;
category values;
date fields;
park references;
public URLs;
API consumers; and
mobile application dependencies.
Step 1 — Understand the Source
Bluefly determines:
Where does the data live? Which templates use it? What fields are required? What relationships exist? Which APIs consume it? Which URLs must survive? What variations exist across the records?
Step 2 — Define the Target
For example:
Legacy Park Alert ↓ Drupal Park Alert entity/content type
The target definition might specify:
title;
alert type;
affected park;
publication dates;
severity;
body content;
media;
taxonomy;
canonical URL;
API representation; and
publishing permissions.
The exact model is an architecture decision, not something automation invents.
Step 3 — Build the Migration
Bluefly implements the representative migration:
MSSQL ↓ Source extraction ↓ Normalization / transformation ↓ Drupal Migrate ↓ Drupal entities ↓ API / page output
This is actual executable code.
Step 4 — Validate It
The Factory evaluates evidence such as:
SOURCE RECORDS EXPECTED: 1,937 MIGRATED SUCCESSFULLY: 1,900 EXCEPTIONS: 37
REQUIRED FIELD VALIDATION: PASS RELATIONSHIP VALIDATION: PASS URL VALIDATION: PASS API CONTRACT VALIDATION: PASS
A successful migration is not established because someone says, "It looks right."
It is established through explicit acceptance evidence.
Step 5 — Route Exceptions
Suppose 37 records contain a legacy variation the migration pattern does not understand.
The Factory does not guess.
It creates an exception:
PATTERN: PA-001 OBJECTS AFFECTED: 37 EXPECTED: standard Park Alert relationship OBSERVED: historical relationship variant DECISION REQUIRED: senior engineer
A qualified engineer reviews the evidence.
If the variation is genuinely unique, it remains an exception.
If the solution applies repeatedly, Bluefly updates the migration pattern and reruns the affected records.
That means human judgment improves the Factory rather than disappearing into a one-time troubleshooting session.
The Compounding Model
This is the important part.
Traditional migration delivery often looks like:
Engineer encounters problem → engineer solves problem → migration continues → knowledge remains with engineer → another engineer encounters similar problem → problem is solved again
The Migration Factory changes that to:
Problem discovered → senior engineer decides → decision becomes reusable pattern → Factory repeats pattern → exceptions return to senior engineer → pattern improves
The goal is not to remove senior engineers.
The goal is to stop spending senior-engineer time on work that has already been understood.
The Eight-Week Engagement
For the current Forum One model, Bluefly has proposed an 8-week, fixed-fee Discovery & Architecture engagement at $100,000.
The engagement is designed to move far beyond assessment.
Weeks 1–2 — Discover and Classify
inventory legacy systems;
identify dependencies;
classify components;
identify representative complexity;
establish initial migration families;
identify APIs and external consumers;
identify architectural unknowns.
Weeks 3–4 — Define the Target and Patterns
establish Drupal target architecture;
define source-to-target mappings;
select representative migration families;
define validation requirements;
separate deterministic work, agent-assisted work, and human decisions.
Weeks 5–6 — Build and Prove
implement representative migration code;
build reusable transformation patterns;
create automated validation;
establish exception handling;
execute representative migration slices;
test API and integration parity where applicable.
Weeks 7–8 — Operationalize the Plan
refine the migration family catalog;
document proven patterns and known exceptions;
define migration waves;
produce implementation backlog and ROM;
establish acceptance criteria;
define operating procedures;
prepare the implementation-team handoff;
identify the first production migration wave.
What Exists at the End of Week Eight
Forum One should be able to point to tangible assets, not simply a recommendation deck.
The expected handoff is:
Estate
classified legacy inventory;
dependency map;
migration-family catalog;
exception/risk inventory.
Architecture
Drupal target architecture;
integration/API decisions;
source-to-target mapping rules;
migration standards.
Working Engineering Assets
representative migration code;
reusable migration patterns;
transformation logic;
tests;
validation tooling;
CI/CD quality gates where applicable.
Proof
one or more representative migrations executed end to end;
migration evidence;
identified exceptions;
documented human decisions;
acceptance results.
Execution Plan
migration-wave strategy;
prioritized backlog;
implementation ROM;
dependencies;
staffing assumptions;
first production-wave definition;
runbooks and operating guidance.
The test is simple:
Could another qualified implementation team continue the migration without asking Bluefly to reconstruct eight weeks of thinking from memory?
If not, the handoff is incomplete.
What This Engagement Is Not
It is not staff augmentation.
Bluefly manages the senior multidisciplinary effort necessary to produce the defined outcome.
The customer is not buying a number of developers multiplied by a number of hours.
It is not a full estate migration.
The eight-week engagement proves representative migration patterns and turns the overall estate into an executable implementation plan.
Production migration waves follow separately.
It is not an AI experiment.
AI and agent-assisted techniques may be used where they improve speed, classification, engineering assistance, validation, or exception analysis.
They are implementation mechanisms.
The customer buys a reliable migration outcome with evidence and human accountability.
It is not a documentation-only discovery.
Architecture and documentation matter, but the engagement must include working representative implementation and validation.
Human Judgment Stays Explicit
Bluefly deliberately separates three kinds of work.
Deterministic Automation
Work where the rule is known and repeatable.
Examples:
extracting known schemas;
applying approved mappings;
executing known transformations;
counting and comparing records;
running tests;
checking required fields;
validating known API contracts.
Agent-Assisted Engineering
Work where AI can accelerate a qualified engineer without becoming the final authority.
Examples:
component classification;
pattern matching;
source-code analysis;
migration scaffolding;
test generation;
anomaly analysis;
documentation assistance.
Human Engineering Decisions
Work requiring accountable judgment.
Examples:
target architecture;
ambiguous source semantics;
security decisions;
API compatibility tradeoffs;
unresolved business rules;
exception disposition;
risk acceptance;
customer acceptance.
This boundary is fundamental to the Factory.
Phase 2 — Migration Factory Activation
Once the eight-week engagement proves the approach, the next logical engagement is to operationalize it for production.
A planning range discussed for this phase is approximately $40,000–$60,000 fixed fee, subject to the actual findings and implementation environment.
Potential scope includes:
install and configure production migration tooling;
operationalize repositories and workflows;
establish CI/CD gates;
convert representative patterns into production-ready procedures;
onboard Forum One engineers;
establish evidence and exception workflows;
pair through the first production migration wave;
deliver operating runbooks; and
prove that the implementation team can run the system.
The purpose is to cross the boundary from:
"We proved how this migration should work."
to:
"The production team is now operating the migration system."
Phase 3 — Migration Waves
Once the Factory is operational, production work can be structured around bounded migration families or waves.
A wave can have:
DEFINED SOURCE POPULATION + APPROVED PATTERNS + ACCEPTANCE CRITERIA + EXCEPTION BOUNDARY + VALIDATION REQUIREMENTS = BOUNDED DELIVERY PACKAGE
This creates alternatives to pure time-and-materials delivery.
Bluefly can price and manage work around migration families, waves, milestones, or bounded outcomes while separately handling genuinely unbounded exceptions.
The Commercial Idea
The Migration Factory changes the economic unit of migration.
Instead of selling:
two senior Drupal engineers for six months
Bluefly can increasingly sell:
a governed migration capability that converts an unknown estate into repeatable execution, with senior engineers responsible for architecture, exceptions, and acceptance.
Embedded engineers can still be part of the engagement.
But they become operators of the system, not the product being sold.
Why a Partner Can Sell This
A partner such as Acquia, Forum One, or another systems integrator does not need to explain Bluefly's internal Factory architecture.
They need to recognize a customer situation:
"This organization has a large legacy estate, knows it needs to move to Drupal, but cannot confidently estimate, standardize, validate, or scale the migration."
The introduction can then be simple:
Bluefly spends eight weeks turning the unknown estate into a proven migration system your implementation team can execute.
Or more concretely:
Bluefly classifies the estate, defines the Drupal target, creates reusable migration patterns, writes and proves representative migration code, automates validation, identifies exceptions, and leaves the implementation team with executable migration waves.
That is the offer.
The Proof Standard
Bluefly should not call the Migration Factory repeatable because the concept sounds good.
For this offer to become a proven Bluefly capability:
the representative migration system must work in a real customer engagement;
the implementation team must be able to use the resulting assets;
validation and exception handling must produce usable evidence;
Bluefly must capture reusable capability from the engagement; and
at least one meaningful portion of that capability must survive a second real use.
Until then, this is a deliberately structured commercial experiment being proven through delivery.
One-Sentence Definition
Bluefly's Migration Factory turns a complex legacy estate into a smaller number of proven, executable migration patterns—complete with working code, automated validation, exception handling, human decision points, and a production-ready backlog for scaling the migration.
The Outcome
The customer should leave the engagement knowing:
WHAT exists WHAT is moving WHERE it is moving HOW recurring migration patterns work WHICH code executes those patterns HOW success is validated WHICH exceptions still require humans WHAT the first production waves are WHO owns the next decisions WHAT evidence proves readiness
That is materially different from traditional discovery.
It is the conversion of uncertainty into governed, executable migration capability.