Questions about migration with Pikiner

Pikiner migrates the agreed behavior of a working digital product to a new system built on Java, Spring, PostgreSQL, and TypeScript.

We do not translate old code line by line and do not repair the existing architecture. The working product is used as the executable specification, and the new implementation is built alongside the running system.

Product migration

Once the hypothesis is proven, the task of the system changes.

The product now has to do more than demonstrate value: it has to work securely with users and data, withstand growth, support regular changes, and stay manageable.

If the technical foundation was built primarily for rapid prototyping, its limits begin to take up more and more of the team's time.

A migration replaces that foundation without turning the old implementation into the new one piece by piece.

No.

An MVP built quickly may have performed its task perfectly: proving a hypothesis at minimal cost and letting the company reach users or investors sooner.

The problem does not arise because the first implementation was necessarily a mistake. It arises because, once the product is proven, requirements are placed on it that it was never designed for.

No. Pikiner is not an emergency repair service for old code.

We build a new implementation with an end state defined in advance.

If a single production defect has to be fixed immediately, a failed system has to be restored, or the existing codebase has to keep being supported, that work needs a different provider.

We need a working product that can be demonstrated from the perspective of its real roles, journeys, and business rules.

It does not have to be a large or mass-market service. The product may be at the stage of pilots or first users, provided its core hypothesis is proven and the behavior to be migrated can be seen and verified.

No.

Funding may be a sign that the company is ready for the next stage, but it is not a technical condition.

What matters more is that the product works, its value is confirmed, the company controls the decision to migrate, and a budget exists for a defined project.

Possibly, if it already runs in a substantive pilot, can be demonstrated, and its core hypothesis is confirmed by future users or customers.

If the product exists mainly as requirements, mockups, or unfinished functions, Pikiner cannot use it as an executable specification.

No, not within this service.

Pikiner specializes in migrating a product that already works to a new technical foundation.

Building and validating a new hypothesis requires a different process, in which the functional scope changes as the team learns.

No.

We can study the existing system to the extent required to define the migration, but we do not offer hourly refactoring, the debugging of individual services, or continued support of the old codebase.

No.

Before a proposal, we check the technical compatibility of the product with the Pikiner production pipeline.

We examine the roles, the journeys, the data, the integrations, the infrastructure constraints, and the components the new implementation will require.

If a technical incompatibility is found, we report it as soon as it becomes apparent and explain the specific limit of our method.

Being unable to size the scope or the price quickly is not in itself a reason to decline. If a project is technically compatible, we continue studying it at no charge until we can prepare a fixed proposal.

For example:

• releases are becoming riskier;
• fixing one problem regularly creates another;
• the team finds it hard to explain the actual dependencies of the system;
• access rights and security rest on agreements between people rather than on architectural constraints;
• growth in users or data keeps requiring new workarounds;
• a significant share of the time goes on infrastructure problems;
• an investor or a corporate customer requires a predictable production system;
• further development is limited by the design of the current implementation rather than by product strategy.

One sign alone does not prove that a full migration is necessary. The first demonstration exists precisely to check whether the method applies.

The working product is the basis.

During the demonstration, the client shows the user and administrative roles, the main journeys, the business rules, the integrations, and the important data states.

From that, an agreed baseline is formed: a list of behavior and results, fixed in the SOW.

That baseline is what the new system is developed and accepted against.

The old code may be used as an additional source of information where that is required to understand a particular behavior or technical constraint.

We do not migrate the structure of the old repository, its architectural decisions, or its implementation line by line.

The new system reproduces the agreed behavior of the product on a new technical and architectural foundation.

No.

At the first stage we are interested in the product itself: how it works, which roles exist in it, which tasks its users perform, and which rules determine the outcome.

Access to the repository may be required later, to answer specific technical questions. Its extent and the way it is provided are agreed separately.

It is not a condition of the first demonstration, but the information is useful.

We want to understand:

• which stack the current system runs on;
• how it is deployed;
• which main applications and services it consists of;
• where the data is held;
• which external systems are connected to it;
• which limits of the current implementation the team considers most significant.

This helps separate the problems of the chosen stack from the problems of a particular architecture, and determines which additional materials may be needed.

Not necessarily before the first demonstration.

Later we may request the structure of the repository from its root directory, a description of the services, the data schema, documentation on the integrations, or access to particular parts of the code.

We request only the materials genuinely required to determine the scope and the technical compatibility.

If that behavior has to be preserved, the client has to demonstrate or describe it before the baseline is approved.

It is included in the migration only after it is explicitly recorded in the SOW.

Hidden logic that is undescribed or unavailable for verification cannot automatically be treated as part of the agreed result.

New features are not included in the main migration.

The task of the project is to reproduce the agreed behavior of the existing product on a new technical foundation.

New functionality changes the baseline being verified, increases uncertainty, and makes it impossible to compare the two systems objectively.

Such changes can be planned after the migration or arranged as a separate project.

Once the SOW is approved, the agreed baseline is fixed.

The client team can go on developing the running system, but new features and changes in behavior do not automatically become part of the migration.

If the client wants such a change included in the new system, the parties separately agree its effect on the scope, the price, and the date.

Yes, if the data migration is explicitly included in the SOW.

Before the project begins, the parties determine:

• which data is migrated;
• the sources and the format;
• the transformation rules;
• the checks for completeness and correctness;
• the acceptable window of restricted operation;
• the switchover procedure;
• the rollback plan.

Migrating production data is not treated as automatically included in every project.

Agreed integrations can be part of the migration.

For each one it is necessary to define the interface, the owner of the external system, the availability of a test environment, the constraints of the provider, and the criteria for correct operation.

The client receives a deployment-ready project containing the agreed functionality, the configuration, the database migrations, the tests, and the instructions required.

The project has to build and deploy without access to the internal module storage of Pikiner and without a valid Gabion license.

Actually setting up the production infrastructure, the cloud accounts, DNS, and the external services, and switching users over, are part of the work only when the SOW states so explicitly.

A deployment-ready result is part of the project.

The practical deployment into the infrastructure of the client, configuring the cloud services, transferring the secrets, DNS, and the production switchover itself are determined separately for each project and have to be explicitly included in the SOW.

If the migration is performed without a redesign, the original working product serves as the visual baseline.

The new system has to reproduce the agreed interface and behavior accurately enough for the result to be compared objectively with the original product.

If the result differs from the agreed baseline, Pikiner resolves the discrepancy within the project.

Yes, but a redesign is a separately paid part of the project and is not included in the standard cost of the migration.

Before the SOW is approved, the client has to provide a complete agreed package of redesign materials that does not change the business logic of the product.

That package has to contain all the mockups, states, responsive variants, components, and interface behavior rules required.

Pikiner implements the agreed design but does not run an iterative process of arriving at it, and does not rework a finished interface on the basis of new visual preferences that emerge during the work.

After the project is handed over, the client can continue the visual development of the system independently, including with Gabion.

With a free demonstration of the client's working product.

At that meeting it is the client who shows us their product: the real roles, the user and administrative journeys, the business rules, the data, and the important integrations.

It is not a presentation of Gabion and not a technical audit of the repository.

After the demonstration we say whether we see technical limits to applying the Pikiner method, and which information is needed next.

It is enough to have:

• access to a demonstration or working version of the product;
• a person who understands the main user and administrative journeys;
• a brief explanation of the company's current stage;
• a description of the reason a migration is being considered;
• a list of the integrations and constraints that matter most;
• information about confidentiality requirements.

There is no need to prepare in advance:

• a tidied-up repository;
• a technical audit;
• full documentation;
• your own estimate of the rewrite;
• the whole source code;
• a decision about the project before the conversation.

No.

The first demonstration of the product of the client, and the subsequent determination of technical compatibility and scope, are not billed.

Pikiner does not use a free first meeting as the entry point to a mandatory paid study.

If a project is technically compatible with our pipeline, we request and study the necessary materials at no charge until we can prepare a fixed proposal.

If the project looks compatible with the Pikiner method, we determine the next minimum set of information required.

Depending on the product, that may be:

• further demonstrations of particular journeys;
• a description of the roles and access rights;
• the current technology stack;
• the structure of the repository;
• the data schema;
• a list of the integrations;
• documentation;
• access to particular parts of the code;
• written answers from the client team.

If a technical incompatibility is found immediately, we report it as soon as that becomes apparent.

The Gabion Live Showcase is a separate free meeting for a project that is initially suitable for the Pikiner method.

At it, the Pikiner team demonstrates Gabion at work: creating and verifying changes, the architectural constraints, the handling of real errors, and the behavior of the development environment.

It is not the first demonstration and not a trial migration of the product of the client.

First the client shows Pikiner their product. After that, if continuing the conversation makes sense, Pikiner may separately demonstrate Gabion.

The working reference point for a typical project is $75,000 USD.

Most of the migrations under consideration are expected to fall in the range of $60,000–120,000 USD.

The final price depends on the agreed functional scope, the data, the roles, the integrations, and any special components.

The price is named after the scope is determined and is fixed before the work begins.

Taxes, cloud infrastructure, external APIs, LLMs, and other third-party services are not included in the stated price unless the SOW explicitly provides otherwise.

We work not with an undefined idea but with an existing product whose behavior can be seen, described, and recorded.

The stack, the architectural rules, the Runtime, and the production process of Pikiner are defined in Gabion in advance.

Before the proposal, we study the product to the extent required to fix the result. After that, Pikiner takes on the risks of its own estimate, of the architectural implementation, and of building any missing reusable modules.

The date is determined after a specific product has been assessed, and is part of the proposal and the SOW.

We do not publish a universal duration: the same number of screens can conceal entirely different amounts of business logic, data, and integrations.

If the agreed SOW and baseline do not change, the price and the date do not change on the side of Pikiner.

A missing internal module, the difficulty of building one, an error in our estimate, or any other internal circumstance at Pikiner is not grounds for increasing the price or moving the date.

A change is possible only when the client changes the agreed scope, or when an external dependency defined explicitly in the SOW arises.

The effect of any change is agreed before the additional work begins.

No.

The new implementation is built in parallel, and the current product goes on serving its users.

A limited window may be required for the data migration or the production switchover itself. Where that is necessary, the scenario, the acceptable downtime, and the rollback procedure are determined in advance.

Yes.

The client has access to the current build of the new system and can verify it before the final acceptance and the switchover of users.

The client verifies the new system against the behavior, the interface, and the scenarios fixed in the SOW and the baseline.

The standard acceptance period is 10 working days from the result being provided for acceptance.

If an agreed function is missing or works differently, Pikiner resolves the discrepancy within the project.

If a finding concerns a function, a change, or a visual requirement that is not in the agreed baseline, it is not treated as a defect of the migration.

The exact procedure for providing the build, recording findings, re-verifying, and completing acceptance is fixed in the contract.

Yes.

The standard warranty period is 60 calendar days after the production switchover.

If the client postpones the launch of a system already accepted, the warranty period begins no later than 30 calendar days after acceptance.

The warranty covers discrepancies between the system handed over and the agreed SOW.

It does not cover new functionality, changes made by the client or by third parties, problems at external providers, infrastructure outside the responsibility of Pikiner, or further changes to the product.

No.

A standard migration does not include continuous monitoring, on-call, an SLA, operating the infrastructure, or open-ended maintenance of the production system.

After the handover the product can be maintained by the client team, by a contractor it chooses, or by another engineering team.

No.

Preserving the product knowledge of the existing team is one of the goals of the method.

The people who developed the product go on understanding its users, its business logic, and the priorities of the company.

After the migration they can set the tasks, verify the result, and continue developing the new system with AI tools and Gabion, or without Gabion.

Having a separate new Java team is not a condition of starting a migration or of owning the product afterwards.

Gabion provides a consistent architecture, ready-built modules, and deterministic checks, and the AI helps with the technology stack.

That does not remove the engineering responsibility of the team. It has to understand the product, assess changes, and control the result, but it does not have to master the whole set of internal Gabion technologies in advance.

The client may also hire Java developers or hand further development to another team.

No.

The CTO may have made the right decisions for the stage of proving the hypothesis, the resources available, and the speed required.

The transition means the task of the system has changed.

We do not build a proposal on devaluing the team of the client, and we do not use a migration as a public post-mortem of the previous implementation.

The client team.

Pikiner is responsible for the production method and the new implementation, but cannot decide, in place of the product owner, what an ambiguous business rule means, choose a new user journey, or approve a new feature.

Ambiguities that affect the baseline have to be resolved before the SOW is approved.

Yes.

The baseline of the migration stays fixed regardless.

New features and changes released after it was fixed are not automatically included in the new implementation.

That lets the client keep working without turning the migration into a target that moves continuously.

Gabion is the environment Pikiner developed for building, verifying, and further developing software systems together with an AI.

It is not a language model of its own, and not a chatbot.

Gabion sets a consistent stack and architecture, assembles the application from modules, and runs deterministic checks at the points where an AI can produce convincing but architecturally incorrect code.

A Gabion module is a complete vertical element of the system, described in gabion.manifest.json.

Depending on the task, a module may include:

• Java code;
• Spring components;
• TypeScript;
• Thymeleaf templates and page sections;
• CSS;
• configuration;
• Flyway migrations;
• tests and checks.

Modules interact through defined Gabion contracts and must not depend directly on the internal details of one another.

That makes it possible to assemble a project from verifiable components while preserving the architectural boundaries of the system.

No.

The internal storage of Pikiner holds anonymized reusable module templates.

When a module is included in the project of the client, its code becomes part of that separate client project.

In production, the application of the client does not load modules from the storage of Pikiner and does not require a connection to it.

The architectural constraints and the main checks of Gabion are not required to rely on an LLM.

Gabion was built to work with AI assistants and agents as external participants in the process, while the critical rules of the system are verified deterministically.

Gabion is designed independently of any single LLM provider and can be used with different models, including local ones.

The actual compatibility and the recommended configurations are described on the Gabion site.

Yes, if the chosen model is capable of working in the scenario required.

The architectural constraints and the deterministic checks of Gabion reduce the effect of model errors, but they do not make all models equal in capability, quality, or speed.

The client receives the project edition of Gabion for the first year, on the terms fixed in the contract and the license.

It is intended for the further development of the product handed over.

The client edition does not include the internal Pikiner functions for creating new independent projects and managing the shared module storage.

No.

Gabion Runtime, the internal module storage, the CLI functions of the production pipeline, and the pre-existing technologies of Pikiner remain the property of Pikiner.

All the code in the project handed over to the client belongs to the client.

No.

Gabion is used during development but is not a mandatory production dependency of the application.

The system handed over has to build, deploy, and serve its users without an active Gabion session, without access to the internal module storage of Pikiner, and without a valid Gabion token.

The product keeps running.

The client keeps the code, the data, the configuration, and all the functionality handed over.

What ends is access to those capabilities of the Gabion development environment that require a valid license.

Further development can continue without Gabion, with an in-house team or with another contractor.

No.

The token governs access to Gabion as a development tool.

It does not switch the production application of the client on or off.

Everything in the directory of the client project handed over belongs to the client, including the code of the modules included in that project.

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

The specific implementation included in the client's project directory belongs to the client.

If Pikiner creates a new anonymized reusable module template outside the project of the client in order to implement it, that template belongs to Pikiner.

Such a template must not contain:

• data of the client;
• secrets;
• the name of the client or of their product;
• source code of the previous system;
• unique business logic of the client;
• other information that would make it possible to reconstruct how a specific product is built.

The project of the client includes its own code. Only the anonymized reusable template stays in the internal storage of Pikiner.

Yes.

The new system is a standard project on the agreed technology stack.

Involving Pikiner is not required to operate it or to develop it further.

The contract is concluded with Pikiner Inc.

The exact registration details, the governing law, the procedure for transferring IP, and the remaining legal terms are stated in the contract.

The product data stays under the client's control.

The rights and obligations of the parties in processing, storing, transferring, and deleting it are fixed by the contract and the applicable confidentiality documents.

Not always.

For development and verification it is preferable to use the minimum volume of data required, anonymized copies, or synthetic sets, where the project allows it.

If access to production data is necessary, the parties determine its purpose, its scope, how it is protected, and for how long, in advance.

That depends on the agreed way of working.

Gabion can work with different LLMs, including local ones, which makes it possible to choose the arrangement according to the requirements for data, security, and cost.

Before the project begins, the parties determine:

• which models and providers are permitted;
• which material may be sent to an external provider;
• which data has to stay in a controlled environment;
• which additional restrictions apply to source code, data, and secrets.

Wherever possible, the production infrastructure and the external services are registered to the accounts of the client.

If Pikiner requires access, the client provides separate limited credentials for the period required.

How access is provided, stored, and revoked is determined before the relevant work begins.

Yes.

The client receives their own project on a standard technology stack.

It can be developed with Gabion, with ordinary AI tools, with an in-house engineering team, or with another contractor.

No.

Renewing Gabion is not a condition of the production application running, and it does not restrict the rights of the client to the code handed over.

How source code, data, access, backups, and project materials are retained and deleted is determined by the contract and the applicable policies.

Once the work is complete, temporary access has to be revoked and the materials Pikiner is not required to retain deleted by the agreed procedure.

Not automatically.

Access granted to perform the project has to be limited to that task and to a period.

Once the relevant work is complete, the client revokes it or separately confirms that further access is required.

Ongoing maintenance is not part of a standard migration.

If the parties require separate work after the warranty, it has to have its own scope and terms.

The client does not depend on Pikiner and can choose any suitable team.

Go to the contact page and describe briefly:

• what the product does;
• which stage it is at;
• why the company is considering a migration;
• which roles and main journeys can be demonstrated;
• whether an NDA is required before the demonstration.

The repository, production data, and confidential documents do not need to be attached to the first form.

Pikiner contacts the client, settles the organizational details, and proposes a time for a free demonstration of the working product.

At the first meeting, the client demonstrates their system to Pikiner.

If the project is initially suitable for the production method of Pikiner, the next step may be a request for further materials and a separate Gabion Live Showcase.