Markdown version

Migration of a working product

Migrate a proven product to a stack designed for its future.

Pikiner reproduces the agreed behavior of a working product in a new system built on Java, Spring, PostgreSQL, and TypeScript.

The existing version continues to operate during the project. Before development begins, we define the boundaries of the migration and fix the price and the delivery date.

Show Us Your Product Check If You Fit
  • The working product is used as the specification
  • The new implementation is built alongside the current one
  • The agreed result is verified before users are switched over
  • The client team continues development after handover

The MVP has answered its question. The system now has to become a product.

While a team is testing its hypothesis, its main task is to put a working result in front of users as quickly as possible. At that stage, a prototype stack shortens the path from idea to feedback and performs its role correctly.

Once the hypothesis is proven, the requirements change. The system begins to store more real data, serve several roles, support integrations, release changes on a regular schedule, and operate under growing load. A defect in it now affects users, revenue, and the reputation of the company rather than a test build.

At that boundary, Pikiner replaces the technical foundation of the product while preserving business logic that is already proven.

A transition does not mean the MVP was built incorrectly. It means the product has outgrown the task its first implementation was built for.

There is no need to wait for a failure

The limits of a prototype implementation rarely appear as a single obvious breakdown. Debugging time grows first, releases become more complex, the number of dependencies between services increases, and individual fixes begin to create new problems elsewhere.

At that stage the system can still be kept operational. But every new layer of functionality makes a future transition harder. Migration is therefore best started after the product is proven, and before it becomes an emergency operation.

We do not translate old code into another language.

A line-by-line translation would preserve not only the functions of the product, but also the architectural decisions, the temporary workarounds, and the limits of the previous implementation. A new stack does not repair a system on its own if the old structure is carried into it.

Pikiner migrates the agreed behavior of the product, not its source code. We reimplement user journeys, business rules, access rights, and integrations on a new technical foundation. The key difference:

Not migrated automatically

  • the structure of the old repository;
  • incidental technical dependencies;
  • workarounds for the previous stack;
  • unused fragments of code;
  • architectural debt.

Preserved and reproduced

  • user journeys;
  • business rules;
  • roles and access rights;
  • observable system behavior;
  • agreed integrations.

The old system remains a working reference until the switchover. That makes it possible to compare the actual behavior of the two versions instead of arguing about what the documentation once intended.

The working product becomes the executable specification.

Scoping begins with the client team demonstrating its working system to Pikiner from the perspective of each role: the main journeys, the rules, the exceptions, the administrative functions, the integrations, and the important data states.

From the journeys demonstrated, we compile a list of the behavior that must be present in the new implementation. That list, and not the number of screens or lines of old code, becomes the basis of the proposal and the SOW.

The agreed scope may include:

  • user and administrative journeys;
  • roles and access rules;
  • business rules and calculations;
  • APIs and external integrations;
  • background processes and notifications;
  • reports, export, and import;
  • migration of existing data, if included in the SOW;
  • deployment and infrastructure, if included in the SOW;
  • observability and operational functions agreed for the production environment.

Not included automatically:

  • functions that do not yet exist in the working product;
  • hidden behavior that cannot be learned from the system and was not described by the team;
  • temporarily inoperative journeys not recorded before the project began;
  • changes to business logic presented as migration;
  • cosmetic and product improvements not included in the SOW;
  • repair or continued support of the old codebase.

The product baseline

The baseline is recorded when the SOW is approved:

  • a specific version of the old product;
  • the agreed roles;
  • the journeys being migrated;
  • the business rules;
  • the integrations;
  • the data states;
  • the visual reference;
  • the known exceptions.

The client may continue to operate the old system and release the fixes it requires.

Changes made after the baseline are not automatically included in the migration.

If a change is critical to launching the new system, the parties decide separately whether a change order is required. The client team can migrate the remaining changes after the project is handed over.

New features

New features are not added during the migration.

Pikiner first reproduces and hands over the existing agreed behavior. Further development is carried out after handover through Gabion, with the standard tools of the stack, or under a separate SOW.

Redesign

If a redesign is not included in the SOW, the original product serves as the visual reference within the agreed scope.

If the new implementation differs from that reference, Pikiner corrects the discrepancy. A pixel-perfect requirement applies only when explicitly specified in the SOW.

A separately paid redesign is possible only if a complete, finished package is delivered before the SOW is fixed.

The package must include:

  • all screens;
  • the states;
  • the responsive variants;
  • the design tokens;
  • the assets;
  • the copy;
  • the interaction rules.

A redesign:

  • must not change business logic;
  • becomes the new visual reference;
  • does not include an iterative design service;
  • does not allow for rework during the migration on subjective request.

After handover, the client can continue the visual development of the project through Gabion or with another team.

If a function has to appear for the first time, that is new development. If existing behavior has to be preserved in the new system, that is migration.

Two systems run in parallel until the switchover.

  1. 1. The client demonstrates the product to Pikiner

    During the first free meeting, you demonstrate the working system to us: the main roles, the user and administrative journeys, the data, the integrations, and the known limitations.

    It is also useful to name the current stack and the deployment method briefly. If a directory tree from the repository root can be shown without additional preparation, it helps us understand the structure of the project.

    For the first meeting, it is not necessary to run an audit, tidy up the code, hand over the repository, or prepare full technical documentation.

  2. 2. The technical compatibility check

    First, we check the mandatory properties of the product for compatibility with the Pikiner production pipeline.

    If a technical incompatibility becomes apparent, we report it immediately and explain the specific limit.

    If the product is compatible, we continue gathering information at no charge, up to a fixed proposal. Where necessary, we request further demonstrations, documentation, conversations with the team, or limited access to the repository under an NDA.

    For a suitable project, Pikiner may separately offer a free Gabion Live Showcase. It is a second meeting, not this one.

  3. 3. Recording the result

    We agree on the list of the behavior being migrated, the responsibilities of each party, the acceptance criteria, the price, and the delivery date. These terms are fixed in the contract and the SOW.

  4. 4. The new implementation

    Pikiner builds the new system in Java, Spring, PostgreSQL, and TypeScript. The current product continues to serve its users throughout.

  5. 5. Verification by the client

    You receive access to the current version of the new system and work through the agreed scenarios. Discrepancies between the recorded behavior and the new implementation are resolved within the project.

  6. 6. Data migration and switchover

    If migrating production data is part of the SOW, the sources, the volume, the transformation, the cleanup, a trial migration, the completeness check, acceptable downtime, cutover, and rollback are recorded in advance.

    After acceptance, the parties choose the moment to switch users over to the new system.

  7. 7. Handover

    The client receives the application code, the agreed operational materials, and the project edition of Gabion, which allows the existing team to continue development.

Instead of infrequent presentations built around a prepared script, the client has access to the current build and can see the state of the project as it develops.

Not an architectural prototype, but a working product.

Within the approved SOW, the result of the project includes:

  • a new implementation of the agreed product functions;
  • the application source code;
  • the data schema and structure;
  • the implemented roles and access rules;
  • the agreed external integrations;
  • the automated checks and tests provided by the production pipeline;
  • the build and deployment configuration for the agreed environment;
  • operational and project documentation within the agreed scope;
  • access for the existing team to the project edition of Gabion for the first year;
  • the materials and access rights required to continue the work independently.

A deployment-ready result

The standard result is deployment-ready.

It includes:

  • the build configuration;
  • the required deployment configurations;
  • the environment requirements;
  • the instructions;
  • a list of environment variables without secret values.

Creating cloud infrastructure, the actual production deployment, DNS, certificates, secrets, the CI/CD of the client, switching users over, monitoring, and rollback are included only when explicitly specified in the SOW.

Production accounts belong to the client wherever possible.

Independence from Gabion

Gabion assists in developing the system but does not become part of its production dependencies.

The application builds, deploys, and runs without an active connection to Gabion. Loss of access to the tool does not stop the product and does not restrict the access of the client to their data.

Ownership of the project and the modules

All code, configuration, migrations, tests, and documentation in the separate directory of the handed-over project belong to the client under the terms of the contract.

Gabion Runtime, the internal module storage, and the anonymized source module templates are outside the project of the client and belong to Pikiner.

If the agreed implementation requires a new module, Pikiner builds it outside the client project as a reusable component, without the data, the secrets, or the unique business logic of the client.

The code and configuration that enter the project directory when a module is applied remain part of the client's project.

Contract, IP, and Independence in Detail

The team does not hand the product over and wait for its return.

No one knows the reasons behind product decisions better than the people who made them and observed how users responded. The client team therefore takes part in defining behavior, answers questions about ambiguous journeys, and verifies the new system.

It does not need to direct the implementation of every technical detail, or to master the new stack before the migration begins. Pikiner is responsible for the new architecture and for delivering the agreed result.

During the project, the client team:

  • demonstrates how the existing system works;
  • provides access to the agreed environments and integrations;
  • explains ambiguous business rules;
  • makes timely decisions on the discrepancies found;
  • verifies the new implementation against the agreed scenarios;
  • prepares the organizational side of switching users over.

After handover

The original team continues to develop the product with AI through Gabion. The team retains the business context, and the tool holds the architectural rules and verifies the critical decisions of the new stack.

How Gabion Supports Human and AI Together

First a defined result. Then a fixed price.

The typical reference point for a project is $75,000 USD. The working range for most migrations is $60,000–120,000 USD.

The price depends on the functional scope: the number of roles and journeys, the data structure, the integrations, and any special components required to reproduce the product.

The age of the old repository and the number of lines of code do not determine the cost on their own, because we do not migrate code line by line.

The final price and date are named after we have seen the product of the client and defined the boundaries. They are fixed before the work begins and do not change unless the agreed scope changes.

Applicable taxes, the cloud infrastructure of the client, external LLMs, third-party service licenses, paid APIs, and vendor fees are not included in the price unless the SOW explicitly states otherwise.

What can change the price or the date after signing

  • a change to the baseline that is critical to launch and that the parties decided to include in the SOW;
  • a change to the agreed integrations;
  • a change to the requirements for data, infrastructure, or deployment;
  • a delay in mandatory decisions or access on the side of the client, where the contract provides for its consequences.

New features are not accepted as a change to the SOW during the migration. They are carried out after the application is handed over.

What is not billed to the client as a separate item

  • the internal development of Gabion;
  • building reusable components of the production pipeline;
  • our own training or research required for our method;
  • the number of internal attempts to implement the agreed result.

Internal complexity, the absence of a ready-made module, and an error in our own estimate are not grounds for changing the price or the date.

If the client proposes a change to the SOW, a change order stating the effect on the price, the date, and the acceptance criteria is agreed before any additional work.

The client may decline the change order. The original SOW then remains in force.

Show Us Your Product

We reduce the unknowns before the project begins.

Ordinary custom development begins with a description of a system that does not exist yet. As it is built, the understanding of the product changes, and with it the scope, the budget, and the schedule.

In our work, the final behavior can already be observed. The running product demonstrates the main journeys, and the repeatable engineering decisions are already part of the Gabion production pipeline.

We do not promise a fixed price for every system.

First, Pikiner checks the product for compatibility with the production pipeline. If the product is compatible, we gather the necessary information at our own expense and continue scoping up to a fixed proposal.

  1. 1. An existing result

    The product already runs, so the parties discuss observable behavior rather than assumed requirements alone.

  2. 2. A predetermined production pipeline

    The stack, the architectural rules, and the critical components are not chosen again for each project.

  3. 3. A compatibility check

    If a mandatory property or requirement of the product is not supported by the production pipeline, we report it immediately. A compatible product goes through free scoping up to a proposal.

A fixed price is not a promise to predict the future. It follows from an observable product, verified compatibility, and a recorded result.

The result is verified against behavior agreed before the work began.

The acceptance criteria are formed together with the scope of the project. For each significant role and function, the scenarios the new system must reproduce are recorded.

The client receives access to the release candidate before users are switched over, and verifies it within 10 working days of written notice of readiness and the provision of working access.

Findings are submitted as a consolidated list of reproducible discrepancies with the SOW. Pikiner resolves those discrepancies, after which the client re-verifies the affected scenarios.

Acceptance is not used to add functions that were not in the agreed scope. Those are carried out after the application is handed over, and do not call into question the part of the migration already delivered.

  1. the agreed scenarios
  2. access to the new system
  3. verification by the client
  4. resolution of discrepancies
  5. written acceptance
  6. agreement on the switchover

Warranty

After acceptance, a warranty of 60 calendar days runs from production cutover, but no later than 30 calendar days after acceptance if the client postpones the launch.

It covers reproducible discrepancies with the accepted SOW that are attributable to Pikiner.

The warranty does not cover:

  • new requirements;
  • changes made by the client;
  • changes made by another team;
  • changes made by third parties;
  • changes in external services;
  • an environment that was not agreed;
  • infrastructure outside the responsibility of Pikiner;
  • data whose migration was not part of the SOW.

The warranty is not monitoring, on-call, or operational support.

Ongoing support of the production application is not part of the migration. Further work is possible under a separate SOW, with no SLA promised in advance.

Questions About Acceptance and Scope Changes

The method starts with a working product.

A project is suitable for preliminary assessment if:

  • the product runs, and the client can demonstrate it to our team in substance;
  • its core hypothesis is proven;
  • most of the business logic to be migrated is already implemented;
  • the client controls the decision to change the stack;
  • the old system can keep running for the duration of the project;
  • the team is able to verify scenarios and make decisions;
  • the next stage requires greater stability, security, manageability, or readiness for load.

We do not accept a project for a standard migration if:

  • the product itself has to be defined first;
  • the core functionality is not yet determined;
  • the client wants only to debug or partly refactor the old codebase;
  • a mandatory incompatible stack has to be preserved;
  • the product cannot be demonstrated, and the requirements cannot be recorded any other way;
  • the scope consists mainly of unique components that do not fit the Pikiner production method;
  • the client expects a permanent general-purpose outsourcing team rather than a defined migration result.

If a technical incompatibility with the Pikiner production pipeline is detected, we report it as soon as it becomes apparent and name the specific technical limit.

This is not an assessment of product quality, and it does not follow from Pikiner being unable to determine the scope or the price.

The migration has defined boundaries.

Within this service, Pikiner does not offer:

  • development of a new MVP from an idea;
  • urgent fixes for individual defects in the old code;
  • incremental refactoring of the existing architecture with no defined end state;
  • hourly rental of individual developers;
  • ongoing management of the client's product team;
  • a replacement for a CTO;
  • automatic migration of every historical decision from the old system;
  • open-ended responsibility for developing the product after handover.

These limits are what make it possible to be accountable for a result defined in advance. Anything beyond them is discussed separately and is not included in the proposal by default.

Start with a working system.

Demonstrate the main roles, journeys, and limitations of the product. We determine whether our method applies to it and what information is still missing for a fixed proposal.

If the project is suitable, the next result is not an approximate estimate of hours but a defined scope, price, and delivery date.

Show Us Your Product

Frequently Asked Questions Contract, IP, and Independence