Skip to content

Bluefly Technology Reduction: Delivery Method

How we deliver each stage of the offer. Every field named here is defined once, in delivery-kit.yaml, and every customer artifact is rendered from those fields. Do not add fields here that are not in the kit.

1. Maintenance Review

Customer question: What are we maintaining that we don't need anymore?

  1. Discovery. Run the discovery questionnaire (kit.templates.discovery_questionnaire) with the platform owner, security and the people who do upgrades.
  2. Inventory. Create one inventory_item record per custom piece in scope: modules, integrations, scripts, scheduled jobs, workarounds, credentials and service accounts.
  3. Find the replacement. For each item, establish whether an existing platform the customer already owns now provides the capability. Record EXISTING_PLATFORM_REPLACEMENT, REPLACEMENT_MATURITY and REPLACEMENT_EVIDENCE (a doc link, a release note or a working configuration, not an opinion).
  4. Verdict. Assign exactly one:
  5. KEEP: no mature replacement, or the custom version is required for the outcome.
  6. RETIRE: no longer used or no longer needed. Removed with no replacement.
  7. REPLACE: an existing platform capability does the job.
  8. CONSOLIDATE: several custom pieces do one job. Reduce them to one.
  9. INVESTIGATE: evidence is missing. Name the question and who answers it.
  10. Output. The Deletion Plan (§2), reviewed with the customer.

Rule: INVESTIGATE is not a parking lot. Every one names the missing evidence and its owner, and is resolved before the plan is final or carried as a dated open item.

2. Deletion Plan

The plan contains one deletion_plan_item record for every item whose verdict is not KEEP, plus a short KEEP list with the reason for each.

Rank:

  • NOW: low risk, clear replacement, and it removes upgrade, security or key-person burden.
  • NEXT: clear replacement, but needs scheduling, a dependency removed first, or a longer side-by-side run.
  • LATER: worth doing; blocked on a named, dated event (a platform release, a contract end).
  • KEEP: stays, with the reason recorded.

The plan ends in decisions, not suggestions. Every NOW and NEXT item carries a CUSTOMER_APPROVAL field. The plan is final when every NOW item is approved, declined, or moved to LATER with a reason.

3. Safe Removal (playbook)

Every removal follows the same twelve steps. A step is done when its evidence is recorded in the item's verification record.

  1. Baseline. Record the business outcomes the item delivers today (BEFORE).
  2. Configure the replacement in the existing platform. No new custom code.
  3. Run old and new side by side.
  4. Compare required outcomes against the baseline.
  5. Document differences (KNOWN_DIFFERENCES). Every difference is accepted or fixed.
  6. Customer approves the switch (CUSTOMER_ACCEPTANCE).
  7. Switch the old implementation off. Disable it; don't delete it yet.
  8. Keep bounded rollback. The old implementation can be re-enabled until the rollback window ends. The default is 30 days, longer where the customer's operational or regulatory needs require it. The window is set per item and agreed at approval, not assumed.
  9. Verify production (PRODUCTION_READBACK).
  10. Revoke old credentials and access (OLD_CREDENTIALS_REVOKED).
  11. Remove the old implementation after the rollback window closes (OLD_RUNTIME_DISABLED, OLD_SOURCE_RETIRED).
  12. Record the ownership removed. Update the metrics (§5) and the customer's documentation (DOCUMENTATION_UPDATED).

If a step fails, the item is rolled back, recorded as ROLLED_BACK with the reason, and returns to the plan. It does not count as a removal.

4. Verification contract

A removal counts only when the customer outcome still works. Code disappearing proves nothing. Each removed item has one verification record (fields in the kit), ending in FINAL_VERDICT = PASS | FAIL | ROLLED_BACK.

What Bluefly must be able to show for every PASS: the same required outcome, with less customer-owned machinery.

5. Metrics

Primary measures, counted only from PASS verification records:

Metric Counts Source
CUSTOM_SYSTEMS_RETIRED Items whose old runtime and source are retired verification records
MAINTENANCE_HOURS_RETURNED Hours per year previously spent on the item customer tickets, timesheets, upgrade records
ACCESS_POINTS_CLOSED Credentials, service accounts, keys and endpoints revoked OLD_CREDENTIALS_REVOKED
UPGRADE_TESTING_REMOVED Test cases or test hours no longer needed per upgrade customer test plans
KEY_PERSON_DEPENDENCIES_REMOVED Items that no longer depend on one named person inventory KEY_PERSON_DEPENDENCY

ANNUAL_OWNERSHIP_COST_REMOVED is reported only where the customer's own figures support it.

Every number carries SOURCE, ASSUMPTION and CUSTOMER_CONFIRMED: YES|NO. Unconfirmed numbers are labelled as such and never summed into a headline saving.

6. Maintenance Watch

A short quarterly report, two pages at most unless material evidence needs an appendix. It is not a dashboard.

  • List 1: What can you stop maintaining now? For each item: NEW_PLATFORM_CAPABILITY, CURRENT_CUSTOM_IMPLEMENTATION, WHY_IT_MAY_NOW_BE_REDUNDANT, RECOMMENDED_ACTION. Sources: release notes for the platforms the customer already owns, checked against their inventory.
  • List 2: What are you about to build that you shouldn't? For each item: PROPOSED_CUSTOM_WORK, EXISTING_CAPABILITY, DUPLICATION_RISK, RECOMMENDED_ACTION. Sources: the customer's roadmap and backlog, shared with us each quarter.

Items from List 1 that the customer approves go into the Deletion Plan.

Commercial scope

Sellable Maintenance Review engagement:

Field Definition
CUSTOMER_PROFILE An organisation on established platforms with accumulated customisation. A named platform owner who carries the upgrade cost and the risk register.
BUYING_TRIGGER Any IDEAL_FIT trigger from the qualification worksheet, most often a dated forced upgrade or end of life.
SCOPE_UNIT One bounded estate: N sites, N applications, N repositories, one platform family, one business unit, or one digital estate. Agreed in writing. Never hours.
INCLUDED Discovery, inventory of everything in scope, replacement evidence per item, verdicts, Deletion Plan, and one review session with the customer.
EXCLUDED Carrying out removals (that's Safe Removal), new feature work, platform migrations, and anything outside the agreed scope unit.
CUSTOMER_INPUTS Read access to the in-scope systems and their source; the upgrade and test history; maintenance tickets and hours if they exist; named contacts for platform, security and operations.
BLUEFLY_INPUTS The delivery kit, platform capability research, and a reviewer independent of the person who did the inventory.
DELIVERY_PHASES 1 Discovery → 2 Inventory → 3 Replacement evidence → 4 Verdicts → 5 Deletion Plan review.
TARGET_DURATION Fixed and agreed per scope unit before kickoff. Quoted in weeks, never open-ended.
ACCEPTANCE Every in-scope item has a verdict and evidence. Every NOW/NEXT item has a customer decision. Every INVESTIGATE item has an owner and a date.
EXPANSION_PATH An approved Deletion Plan becomes a Safe Removal engagement. After the first verified removal, Maintenance Watch.

Worked example (illustrative)

Every figure below is an illustrative assumption, not customer evidence. It shows the flow and the record shapes. Real engagements use only the customer's own numbers.

Discovery. A mid-sized organisation runs a content platform. Seven years ago it built a custom approval integration: content changes go to an external workflow tool through a custom connector and come back approved. The connector runs as a scheduled job, uses a long-lived service-account token, and only one developer understands it.

Current cost (illustrative). About 6 hours a month of support, plus about 3 days of regression testing at each of 2 upgrades a year. That's roughly 72 + 48 = 120 hours a year. SOURCE: customer ticket export (assumed). CUSTOMER_CONFIRMED: NO.

Risk. One long-lived token with write access to the platform. One key person. The connector blocks the next platform upgrade, because the API it calls is deprecated.

Replacement. The platform's current release ships a native content-moderation workflow that covers draft, review, approve and publish, with role-based approvers. REPLACEMENT_MATURITY: generally available for two releases. REPLACEMENT_EVIDENCE: vendor documentation plus a working configuration in the customer's test environment. Verdict: REPLACE. Rank: NOW.

Side-by-side proof. For 2 weeks, both paths run in test with the same content. All required outcomes match: approvers, notifications, publish only after approval. One known difference: the native workflow doesn't post to the external tool's activity feed. The customer accepts this, because nobody reads that feed.

Customer approval. Signed by the platform owner and security. Rollback window: 30 days.

Cutover. The native workflow is enabled in production and the connector's scheduled job is disabled. The code isn't deleted yet.

Rollback window. 30 days with the connector disabled but restorable. No rollback was needed.

Credential retirement. The service-account token is revoked, and the account is removed from the external tool and from the platform.

Final result. Verification FINAL_VERDICT: PASS. Same approval outcome, one fewer custom system.

Ownership removed (illustrative):

Metric Value Source Confirmed
CUSTOM_SYSTEMS_RETIRED 1 verification record YES (by construction)
MAINTENANCE_HOURS_RETURNED ~120 h/yr assumed ticket export NO
ACCESS_POINTS_CLOSED 1 token, 1 service account verification record YES (by construction)
UPGRADE_TESTING_REMOVED ~3 days per upgrade assumed test plan NO
KEY_PERSON_DEPENDENCIES_REMOVED 1 inventory YES (by construction)
ANNUAL_OWNERSHIP_COST_REMOVED not reported customer cost data not provided n/a