Migrating Between Launchpads: What Actually Changes

A team switching launch venues carries across almost nothing mechanical. Programs differ, account layouts differ, fee models differ, discovery surfaces differ and every tool configured against the old venue has to be re-pointed. What transfers is knowledge, audience the team owns independently, and the launch plan itself. The bill is operational rather than financial.

What this note is and is not about

This is about a team choosing a different launch venue for a launch, not about a token moving from a bonding curve to an automated market maker pool. Those two events get called migration and they have nothing in common. The curve-to-pool handover is a program instruction that happens to one token at one moment; switching venues is a decision a team makes about where to run its next launch.

The distinction matters because the confusion produces a genuinely wrong belief: that an existing token can somehow be relocated to a different launchpad. It cannot, and the reason is worth stating plainly. A launch venue's job ends when the primary phase ends. After that the token is an ordinary mint trading in ordinary pools, and there is no remaining role for a launchpad to take over.

Nothing mechanical transfers

Every mechanical property of a launch is a property of the venue's program. The curve account layout, the fee routing, the graduation check, the migration instruction and the destination are all implemented in code that belongs to that venue and to nobody else.

The consequence is that a switch is not a configuration change. Anything reading a curve account has to learn a new layout. Anything subscribing to program logs has to subscribe to a different program. Anything computing a price from reserves has to know which reserves are virtual on the new design, which is not usually the same answer.

None of this is difficult and all of it is work. The reason it surprises teams is that the launch experience feels similar - you create a token, it trades on a curve, it graduates - so the mechanical distance between two venues is much larger than the experiential distance.

What carries and what does not

An inventory of what survives a venue switch, what has to be rebuilt, and what was never transferable.
Item	Status	Effort to restore	Note
Existing token	Unaffected	None	The mint is independent of any launchpad once created
Existing holders	Unaffected	None	Balances are recorded against the mint, not against a venue
Existing pools	Unaffected	None	Pools belong to the AMM program, not to the launchpad
Launch plan	Mostly carries	An afternoon	Timing and messaging survive; surface tactics do not
Mechanical knowledge	Partly carries	An afternoon	The four decisions are the same questions with new answers
Monitoring and alerting	Rebuild	Days	New program, new account layout, new log format
Activity tooling	Reconfigure	Hours to days	Depends entirely on whether the tool covers the new programs
Surface instincts	Rebuild	A launch cycle	Knowing what normal looks like takes going through it once
Venue reputation	Does not transfer	Not applicable	Whatever the old venue conferred stays with the old venue
Community familiarity	Partly transfers	Weeks	Your people will have to learn a new interface too

The old token stays exactly where it is

This is worth its own section because it is the single most common misunderstanding. A token created on one venue and graduated to a pool is not attached to that venue in any ongoing way. The mint is an account owned by the token program; balances are associated token accounts referencing the mint; and the pool is an account owned by an AMM program. None of those three has a field pointing at a launchpad.

The account model that makes this true is standard and documented in the Solana documentation. The practical implication is liberating and slightly deflating at once: a launchpad has far less continuing power over a token than either its marketing or its critics suggest. After graduation it is simply a party that ran a sale.

Where residual attachment exists it is usually a fee routing. Some venues arrange for a share of continuing trading fees to flow somewhere, and that arrangement lives in whatever program implements it rather than in the token. Reading a completed post-graduation swap in a block explorer settles whether any such routing applies to a specific token.

Audience transfers only if you own it

The honest test is simple: if you announced your next launch tomorrow, where would you announce it, and would anybody see it? If the answer is your own channels and yes, the audience transfers completely and the venue switch costs you nothing on this axis. If the answer is that people found you because you were on a venue front page, the audience does not transfer at all.

Most teams are somewhere between and overestimate which end they are near. Venue-supplied attention feels like your own attention while it is happening, because the people arriving behave like people who came for you. They did not; they came for the list, and they will be on a different list next week.

This is the strongest argument for treating the discovery surface as a temporary loan rather than as an asset. A launch that builds a channel it controls is buying something that survives a venue switch, a surface algorithm change and the venue itself becoming unfashionable. A launch that relies entirely on surface placement has bought a result rather than a capability.

Tooling is the part with a bill

The financial cost of switching venues is usually small. The operational cost is not, and it concentrates in tooling because tooling is where venue specificity accumulates without anyone deciding it should.

Monitoring keyed to a program id has to be re-keyed, and the log formats it parses will be different.
Price readers that compute a quote from curve reserves need the new design's virtual reserve treatment, which they will not infer.
Alerting thresholds calibrated against one curve's behaviour are meaningless against another's and will either scream or stay silent.
Dashboards keyed to account layouts break entirely, usually by displaying a plausible wrong number rather than an error.
Activity tooling has to support the new venue's programs on both sides of graduation, which is a coverage question with a yes or no answer.
Runbooks written for one venue's failure modes describe failures the new venue does not have and omit the ones it does.

The last two deserve emphasis. Coverage is binary and checkable in advance: either a tool speaks the venue's launch program and its destination program or it does not. Teams running multi-venue volume automation generally discover this at the shortlist stage because it is an obvious question to ask of a tool; teams using something venue-specific discover it on launch day, which is a considerably worse afternoon.

Habits calibrated to the old venue

The subtlest cost is instinct. After a few launches on one venue a team knows what a normal first ten minutes looks like, what a stall at forty per cent means, how quickly the surface refreshes, and when something is genuinely going wrong rather than merely feeling slow.

None of that transfers, and worse, it actively misleads. A pattern that meant trouble on the old venue can be entirely ordinary on the new one, and the team will react to it. A pattern that was a genuine warning sign on the new venue will look unremarkable, because nothing in the old venue's behaviour resembled it.

The mitigation is to run the first launch on a new venue more carefully than the old venue would have required: more observation, fewer interventions, and an explicit note that instincts are not calibrated yet. That is unglamorous advice and it is the difference between one awkward launch and three.

An illustrative cost of switching

Illustrative arithmetic

Invented figures describing no real team. Suppose an operation runs launches with monitoring, a price reader, a dashboard, activity tooling and a runbook, and it is moving from one venue family to another.

Monitoring re-keying and log parsing: two days of engineering. Price reader adaptation to a new virtual reserve treatment: one day, plus half a day to verify against real fills. Dashboard account layouts: one day. Activity tooling: zero if the tool already covers the new programs, several days and a procurement conversation if it does not. Runbook rewrite: half a day, and it will be wrong in places until a launch tests it.

That is roughly a working week of engineering before anything is launched, assuming the tooling coverage question comes back positive. Against that, suppose the new venue's fee arrangement saves a modest amount per launch. The saving would need many launches to repay a week of engineering, which is the arithmetic that makes fee-driven switching rarely worthwhile on its own.

Now change the assumption. Suppose the switch is being made because the new venue's curve fits the distribution goal materially better. That benefit applies to every launch, does not decay, and is not measured in fees at all. The same week of engineering is easy to justify.

The figures are invented. The shape of the conclusion is not: switch for fit, not for price.

Reasons to switch that hold up

A materially better fit between the venue's curve and the distribution the launch actually wants. This is the strongest reason because it applies to every launch and cannot be replicated by working harder on the old venue.

A hard constraint the old venue fails. If a counterparty requires a token account model the old venue does not produce, or provable liquidity commitment it does not provide, there is no decision to make. Constraints are not preferences.

An audience mismatch that has been demonstrated rather than assumed. If launches consistently attract the wrong people and the surface is the plausible cause, moving to a venue whose audience actually overlaps with the target is a reasonable response, provided the team has checked that the old surface was the cause rather than the messaging.

A destination that routes better. If the old venue's destination program is poorly covered by routers and the new one is well covered, the difference is felt by every buyer after graduation. Router coverage models are documented by the operators, including in the Jupiter developer documentation, and can be checked before committing.

Reasons that do not survive scrutiny

A modest fee difference, which rarely repays the operational cost of moving.
The new venue being newer, which is a description rather than an advantage.
A successful launch somebody else had there, which is survivorship reasoning with a chart attached.
Frustration with the previous launch's outcome, which the venue probably did not cause.
A belief that the old venue is declining, which is unfalsifiable and usually irrelevant to a single launch.
Wanting a fresh start, which is a feeling about the team rather than a property of a venue.

Doing it deliberately

Write down what the switch is for in the same one-sentence form as the original venue decision. If the sentence is vague, the switch is a mood.
Check tooling coverage first, because it is binary, it is quick to establish, and a negative answer changes the whole calculation before any other work is done.
Read the new venue's mechanics properly: curve shape and constants, fee components, graduation condition and unit, destination program and provider position handling.
Launch a throwaway token on the new venue and watch it. This is cheap on most venues and teaches more in an hour than any amount of documentation.
Rebuild monitoring and alerting against the new programs, then verify against the throwaway launch rather than against assumptions.
Rewrite the runbook for the new venue's failure modes, and mark which entries are guesses until a real launch tests them.
Run the first real launch conservatively, with more observation and fewer interventions than usual, and write down what surprised you.

Seven steps, most of them cheap, and the sequence matters: coverage before mechanics, mechanics before rebuild, rebuild before anything with stakes attached. Teams that reverse the order end up rebuilding tooling for a venue they subsequently reject, which is the most avoidable cost in the whole exercise and one of the most common.

Questions this desk is asked

Can I move an existing token to a different launchpad?

Not in any meaningful sense. A launch venue creates a token and runs its primary phase; once that phase is over the token exists independently and there is nothing left for another launchpad to run. What people usually mean by this question is launching a second token elsewhere, which is a new launch with all the consequences that implies for holders of the first one.

Does switching venues mean losing my holders?

Holders of an existing token keep exactly what they hold, because the mint is unchanged and no launchpad has any authority over it. What you lose is whatever attention the previous venue was still directing at you, which for most tokens past their launch window is close to nothing. The audience question is about people, not about the venue.

What does ecosystem lock-in actually consist of on a launchpad?

Less than the phrase suggests and more than teams expect. There is no contractual lock-in and no technical barrier to launching elsewhere. What locks a team in is accumulated fit: tooling configured for specific programs, dashboards keyed to specific account layouts, a community used to a specific interface, and instincts calibrated to a specific curve. All of that is rebuildable and none of it is free.

Is it cheaper to stay on a venue you already know?

Usually, in operational terms, and the saving is real but bounded. The rebuild cost of a switch is mostly one-off: reconfiguring tools, relearning a surface, re-establishing what normal looks like. If the new venue fits the goal materially better, the one-off cost is normally recovered quickly. If it fits marginally better, it is not.

Do fees make switching worthwhile?

Rarely on their own. Fee differences between venues are real but modest relative to the operational cost of moving, and the fee component that matters most for a token afterwards is the migration deduction rather than the headline trading rate. Switching for fees alone tends to be a decision that looks rational on a spreadsheet and marginal in practice.

How long does it take to become competent on a new venue?

Assume a full launch cycle before instincts are reliable. Reading the mechanics takes an afternoon; knowing what a normal first hour looks like on that surface, what a stall means, and when something is actually wrong takes going through it once with real stakes. Budget for the first launch on a new venue to be run more carefully than it would have been on the old one.

Should a team ever run launches on two venues at once?

It is possible and it doubles the operational surface. Two venues means two sets of programs, two account layouts, two discovery surfaces to understand and two sets of tooling configuration to keep current. Teams that do it successfully generally have a specific reason, such as different launches genuinely serving different audiences, rather than a desire to hedge.