Will there be an upgrade path from classic to next-gen?
Hi @Team - there havenât been any specifics released as yet but Iâm very confident there will be a migration path developed.
Iâve put together a list of FAQâs that may be helpful for those of you who have access to Classic and Next-Gen, thereâs also a version published here.
Q: Do I have to migrate my Classic app to Next-Gen?
A: No, you do not. Your Classic app and custom code will continue to work as they do today. There is no requirement or deadline to migrate to or start using Next-Gen!
Q: Will my Classic custom code stop working?
A: No. Your Classic custom code will continue to function normally when using the Classic Live App. Classic and Next-Gen are completely separate Live App experiences.
Q: Why are the custom code examples so different between Classic and Next-Gen?
A: Classic and Next-Gen use fundamentally different technologies. Classic uses jQuery and traditional web patterns, while Next-Gen uses React and modern JavaScript patterns. Theyâre essentially two different platforms that share the same database.
Q: If I make changes to my Classic custom code, will it affect my Next-Gen app?
A: No. Classic and Next-Gen custom code are completely isolated from each other. Changes in one version have zero impact on the other version.
Technical Questions
Q: Can I use my existing Classic JavaScript code in Next-Gen?
A: No, Classic JavaScript code wonât work in Next-Gen due to different architectures. If you want to add custom code to Next-Gen, youâll need to write new code using Next-Gen patterns.
Q: Do both versions access the same data?
A: Yes. Both Classic and Next-Gen apps work with the same backend database, so your data is identical in both versions.
Q: Can I have custom code in both Classic and Next-Gen versions of my app?
A: Yes. You can have completely different custom code in each version, and they wonât interfere with each other.
Q: Which version should I use for new custom code?
A: It depends on your needs:
-
If youâre comfortable with your current Classic setup, continue using Classic
-
If you want to explore modern web development patterns, consider Next-Gen
-
If youâre unsure, stick with Classic for now and explore Next-Gen at your own pace
Migration and Planning
Q: Is there a tool to automatically convert Classic code to Next-Gen?
A: No. Due to the fundamental differences in architecture, thereâs no automatic conversion tool yet. Currently, Next-Gen code needs to be written from scratch using Next-Gen patterns.
Q: Should I plan to eventually move to Next-Gen?
A: If it benefits your specific use case. Thereâs no requirement from Knack to migrate. Many customers will continue using Classic and many have already started using Next-Gen.
Q: What happens if I want to try Next-Gen but change my mind?
A: You can switch back to Classic at any time. Since the versions are separate, your Classic app and code remain unchanged while you experiment with Next-Gen.
Q: Will Classic eventually be discontinued?
A: There are no current plans to discontinue Classic. Both versions are supported.
Troubleshooting
Q: My code works in Classic but not in Next-Gen. Whatâs wrong?
A: This is expected. Classic and Next-Gen use different JavaScript patterns and APIs. Code written for one version wonât work in the other.
Q: Iâm getting errors when trying to use Classic methods in Next-Gen.
A: Classic methods (like jQuery selectors) donât exist in Next-Gen. Youâll need to use Next-Gen methods and patterns instead.
Q: Can I copy and paste code examples between Classic and Next-Gen documentation?
A: No. The code examples are version-specific. Always use the documentation that matches your app version.
Summary
You are not required to migrate to Next-Gen custom code. Your Classic apps and existing custom code will continue to work exactly as they do today.
Understanding the Differences
Why Are There Such Major Differences?
Classic and Next-Gen Knack represent two completely different technical approaches:
-
Classic Knack uses traditional web technologies with jQuery-based customization
-
Next-Gen Knack uses modern React-based architecture with different customization patterns and a virtual DOM
Think of them as two separate websites that happen to share the same database. Each version has its own:
-
Custom code editor
-
JavaScript patterns and methods
-
Event system
-
Styling approach
Complete Separation
Your Classic and Next-Gen Live App versions operate independently:
Classic custom code only affects your Classic Live app
Next-Gen custom code only affects your Next-Gen Live app
Changes in one version do not impact the other version at all
Same data is accessible from both versions (they share the backend/builder)
No Migration Required
-
Your existing Classic apps will continue to function normally
-
All your current custom code will keep working
-
You can continue building and maintaining Classic customizations
-
Thereâs no deadline or requirement to switch to Next-Gen
When You Might Consider Next-Gen
You might explore Next-Gen custom code if you:
-
Want to try the latest web development patterns
-
Are starting a completely new project
-
Have specific requirements that benefit from React-based architecture or new CSS classes
Getting Help
If you have questions about:
-
Classic customization - Reference the Classic JavaScript documentation
-
Next-Gen customization - Reference the Next-Gen JavaScript documentation
-
Which version to use - Consider your current setup and future needs
-
Remember: You can use whichever version works best for your needs, and youâre not required to change.
Does this mean the large number of wishlist items will never come to fruition for Classic ?
Hi @RayWindlow47079 good question -
Yes and no. While not every wishlist item for Classic will come to fruition, as you have already seen over the years, we are still investing in Classic for platform level functionalities. 2FA, for example, is a platform level functionality available in both versions.
System fields (watch for updates on that in the next few weeks) will be available in both versions as well, for newly created apps after that release.
That said, the majority of net-new feature innovation will be focused on Next-Gen. Thatâs where weâre concentrating much of our resources to unlock the next wave of functionality.
So, Classic will keep evolving and improving, but the long-term roadmap for brand-new features lies in Next-Gen.
I hope that helps, please let us know what other questions you have!
Cheers,
Kara
Thanks for the reply.
It would be nice to know what will be in the pipeline for implementation and what âainât gonna happenâ.
There are some common items that I believe many are silently waiting/hoping/praying for and it really would be nice to know if they are on the cards.
For example
IF THEN ELSE evaluations in formula fields
Transparency of IMAGES between files via a connection field (big one for me)
Versatility in layout of apps allowing better placement of input fields to eliminate so much white space
Output report functionality (ie more than 1 page ouput to pdf when stored images are involved as in producing a catalogue of records)
Just to list a few I personally would love to see.
We all work around many things because we have to but secretly we are hoping for the day a solution to our problems will be revealed ! So it would be nice to at least know if they are real possibilities rather than just long term and often repeated requests by multiple users that canât or wonât happen.
To my way of thinking KNACK is about the ONLY online database that acts and works like a database should. So many of the other products still think and act like âbloated spreadsheetsâ.
Pleae take this in the spirit it is offered, not so much a criticism, but rather a âpro Knackâ user who would dearly love to see it get better with some highly desirable tweaks to its functionality.
Cheers
Hi, what exactly means âwork with the same backend databaseâ? If I duplicate a Classic app I canât make it in the Next-Gen format and to do so I just realized my only option is to export ALL my tables and re-import them into the new Next-Gen app almost from scratch. Without mentioning what will happen with pages, tasks, email notifications, workflows, JS codes, etc.
Could you explain in detail what advantages we (and our customers by extension) will get from using the new React framework? Would you release a kind of mobile client version to improve performance and/or usability accessing from mobile devices? or itâs just an improvement to get end-users closer to the platform via AI development agents?
Sorry if I sound upset, but I just knew that one of the apps I developed and keep working with for a customer since 2021 must be recreated from zero in order to just use the new Themes features. So in order to offer my customers better features still using Knack, I have to start over with not much options to charge the customer for the extra work Knack is forcing me to do. And if I use an API to connect both apps, the Classic and the Next-Gen one, to the same data, then Iâll be using two apps from my Corporate plan and that doesnât sound too fair.
Iâve been in the IT corp business for 35 yrs and when someone from Product Dev said to me ââŚthe majority of net-new feature innovation will be focused on Next-Gen. Thatâs where weâre concentrating much of our resources to unlock the next wave of functionality.â it really meant that the product end of life was already defined.
I understand the reason why itâs impossible to migrate from one framework to the new one, but if Knack decided to do so I think it would be fair if the change comes along with some tools and/or special incentives (for your loyal developers) to provide a better way to continue offering your platform to our own customers.
Please feel free to schedule time with me, I think it would be good to chat through your concerns in person. My calendar link is here.
what exactly means âwork with the same backend databaseâ? If I duplicate a Classic app I canât make it in the Next-Gen format and to do so I just realized my only option is to export ALL my tables and re-import them into the new Next-Gen app almost from scratch. Without mentioning what will happen with pages, tasks, email notifications, workflows, JS codes, etc.
There is no need to duplicate your app or export/re-import tables. We did our best to make Classic and Knack forwards and backwards compatible as much as possible. What will need to be redone are your Themes (aka Look & Feel), Pivot Tables, and Custom Code. Your tables, pages, tasks, notifications etc do not need to be re-set up.
Could you explain in detail what advantages we (and our customers by extension) will get from using the new React framework? Would you release a kind of mobile client version to improve performance and/or usability accessing from mobile devices? or itâs just an improvement to get end-users closer to the platform via AI development agents?
Moving to the React framework will allow use to implement an SDK for a mobile client, yes.
The new architecture enables us to release faster, and it creates a future-forward platform that is scalable, with a modern looking Live App for your customers.
Sorry if I sound upset, but I just knew that one of the apps I developed and keep working with for a customer since 2021 must be recreated from zero in order to just use the new Themes features. So in order to offer my customers better features still using Knack, I have to start over with not much options to charge the customer for the extra work Knack is forcing me to do. And if I use an API to connect both apps, the Classic and the Next-Gen one, to the same data, then Iâll be using two apps from my Corporate plan and that doesnât sound too fair.
Letâs take a look at this together, as so far, I have not come across an app that needed to be recreated from zero. Also, Knack is not forcing you to use one version or another.
Iâve been in the IT corp business for 35 yrs and when someone from Product Dev said to me ââŚthe majority of net-new feature innovation will be focused on Next-Gen. Thatâs where weâre concentrating much of our resources to unlock the next wave of functionality.â it really meant that the product end of life was already defined.
We have not defined an end-of-life, and we donât have plans to. However, there are a long list of known issues and feature requests with Classic that cannot be fixed or built easily, that are not issues in Next-Gen, and can be built as native features, for example, adding checkboxes to tables in the Live App.
I understand the reason why itâs impossible to migrate from one framework to the new one, but if Knack decided to do so I think it would be fair if the change comes along with some tools and/or special incentives (for your loyal developers) to provide a better way to continue offering your platform to our own customers.
Are you referring to a custom code migration?
I hope to chat with you soon!
Thanks,
Kara
IF THEN ELSE evaluations in formula fields
We are using the same evaluation engine in Next-Gen as we are in Classic (and we still have more work to do here), but I will check in on the feasibility of this with our development team.
Transparency of IMAGES between files via a connection field (big one for me)
Could you give me some more background/details on this?
Versatility in layout of apps allowing better placement of input fields to eliminate so much white space
Hereâs demo, let me know what you think - Layouts đŹ â Tella
Output report functionality (ie more than 1 page ouput to pdf when stored images are involved as in producing a catalogue of records)
This is still an issue to solve (not saying it wonât ever happen, but in Next-Gen, we have to still get to Classic parity before working on this - like implement Payments and Advanced SSO).
Cheers,
Kara
Hi Kara
Thanks for the reply.
So maybe Iâll elbaorate a bit on some of the things I mentioned.
A text formula has very little capacity to handle circumstances where values change or maybe dont even exist when using them to construct pre filled text fields
An example in my case dealing with military records.
We may or may not have details of where the soldier was buried on his passing.
When we create the text field for displaying the information to the public we include all his data that everyone has, name rank, unit, birth, enlistment and death date.
At the end after the death details we want to display the name of the cemetery he is buried in and include text to indicate it is a cemetery name, his grave reference no etc.
These are contained in field called MILITARY-CEMETERY.
If he passed away after the way and thus is buried as a civilian the Cemetery details if we know them are in CIVIL-CEMETERY field.
If its post war we donât display any information only on those deaths whilst in service Military.
The example above shows we currently have to have two fields to achieve this to encompass both case scenarios purely because we cannot test to see if there is a value for display.
The second text formula contains extra text to highlight what the information is
"Buried at " AND âMemorial Referenceâ.
BUT WE HAD TO DO TWO TEXT FORMULAS to accomplish this and create two separate data fields within the file to accompish this.
The first one is for a post war CIVIL BURIAL (sans extra text and data), the second for a WW2 Military Burial with extra text and data.
An IF/THEN evaluation of whether there was anything in the MILITARY-CEMETERY field would have enabled us to have one data field and add the extra text ONLY if the FIELD MILITARY-CEMETERY contained data.
I hope thats a makes sense.
We actually have quite a few such text formulas, the ones for Prisoner of War information for example is far more intensive requiring many formula fields so the correct info could be displayed in a meaningful fashion. This was due to the fact they could be imprisoned in Italy and Germany, or Italy only, or Germany only, and to throw a cat among the pigeons, some of these men were captured later in the war and imprisoned by the Japanese and were imprisoned in Thailand and Japan, or any number of combinations of Thailand, Burma, Japan, Singapore.
Now the obvious common factor that causes this need is the addition of âtext commentsâ added to the data in the field. No matter which approach you take to add descriptions to data to display something meaningful, where the data may or may not exist means multiple text formulas.
This could be resolved by IF/THEN evaluations and subsequently reduce the number of field entries within a file to achieve an end result. We still have the complexity of having to work out which one to use further down the track for display.
This example shows the section being broken into compartments for reproduction on service tributes which is cut and pasted from our app. You can see the effect of adding text to various text formuals where nothing exists in the POW area.
Att the end of day intelligentce built into text formulas would save a lot of work, grief and extra data being written out everytime a record is saved or amended.
NOTE THAT THIS THOUGHT STREAM ALSO APPLIES TO FILTERS.
WHERE WE HAVE AN INITIAL QUALIFIER STATEMENT (field1 is XXX) ANY SUBSEQUENT FILTERS MUST MATCH THE FIRST SUBSEQUENT QUALIFIERS AS EITHER AND or OR (but not a combination of both).
i.e. If field1 is XXX AND field2 is YYYH AND field3 is ZZZ
but we cannot qualify
if field1 is XXX and field2 is YYY or field2 is AAA
because there is no support for AND /OR within filters
REGARDS IMAGES.
I have some 25,000 service records where the men served in anyone of 150 different units and branches of service. Each has a unit color patch identifier.
This is very much a one to many type of datafile.
A unit can be attributed to many soldiers.
Thus the unique data of the Unit is stored in the Unit file including the color patch image.
We can access any of that data, name of unit, country, branch of service FROM THE PERSONNEL FILE using a connection BUT we cannot access an image data from that file.
So to display the unit patch on the record for use in public access we have to create another view altogether using the UNIT FILE AS THE SOURCE.
In the image example that is the area with the photo and unit patch under the heading PERSONNNEL - DATA.
Even in grids you cannot define an accessible field to show IMAGES within a connected file only those stored within the file itself.
This particular point is probably very relevant to people wanting to display a catalogue of products they carry. The product may be from various suppliers and therefore is âglobalâ in its use. But to be able to display it within a grid format listing of products you would have to embed the image within each record to be able to display it on the grid listing.
So basically much more storage space and extreme difficulty if the image needs to be changed at any point. If a connection were capable of displaying an image stored on the global product, one change only required to update every record !
REGARDS LAYOUT
Certainly appear to be improvements but we still have no control over the size of the fields generated inside the app.
Referring back to the previous layout of an app above for example.
The service no is maximum 8 characters at best but we cannot define a precise length or size of the field for it to be displayed. Because of the limitations of screen builder to 3 columns we cannot construct a display in fashion such as a graphic based package like ACCESS where you can size the box according to the amount of data you wish to display. This was even a headache with html but could be accomplished with some leg work. And later html packages did seem to build a lot more versatility in page layout.
We work around such things as the tools are what they are. But some flexibility in layout and positioning of fields on a page would go miles towards making KNACK an absolute must have in my book.
I am thinking though that the âengine in the backgroundâ is not capable of allowing such flexibility in screen design.
Cheers for acknowledging and asking the questions.
I hope it was understandable as my pet peeves sometimes become lunatic ravings 
Hello everyone,
Like many of you, Iâve spent several hundred hours working on my application. The move to Next-Gen raises questions:
-
Whatâs the real benefit for my application, both on the back end and the front end? currently difficult to say for me
-
More importantly, what future is reserved for Classic? Now that both are operational, development and support efforts will likely focus on Next-Gen, which I can understand â but also fear. What about its lifespan? For now, thereâs no forced transition, but what will happen in a year? Two years?
-
My last question: is there within the Knack developer network anyone already able to fully adapt a Classic app to Next-Gen? If so, can these people be identified? In my case, I simply wonât have the time or courage to dive into such a conversion.
In short, this transition brings me a lot of apprehension. I sincerely hope Knack will support its long-standing customers, who have invested a huge amount of time and energy into their applications.
Francois
Hello.! I received an email from Knack yesterday, I guess a lot of people will. Deep in the text, it says that custom code will no longer run on âStarterâ after November 1st. If you got the email, please read it carefully, as this is a significant change. I have queried Support, but as Knack team read these forums, it might be nice to get some response however it comes.
Are you serious, Knack..?
Hi @Francois ,
Iâm sorry to hear you are feeling apprehensive. Our intent with making both Classic and Next-Gen available was to generate a feeling of relief that you can continue using Classic, while giving you the chance to poke around and become familiar with Next-Gen, should you want to.
âWhat will happen in a year? Two years?â There are no plans to discontinue Classic. Both versions are actively supported. When and if that ever changes, you will have plenty of notice. As you can imagine, the majority of our users are on Classic, so it would not make sense to force a transition. From the beginning of this Next-Gen project, weâve known that we will have customers that will stay on Classic indefinitely.
is there within the Knack developer network anyone already able to fully adapt a Classic app to Next-Gen
I will let the developers chime in however, if any of them would like to spend time with the Knack team learning more about Next-Gen, weâd welcome it, just let us know.
Thank you,
Kara
Hi @NeilParkin60970 Thanks for flagging this and for reaching out to Support. I want to clarify a couple of important details:
The correct date is December 1st, 2025 (not November 1st) - so thereâs a bit more time than the post suggests.
I appreciate you bringing it to the communityâs attention so others can prepare. Some context on why we made this decision:
As weâre adjusting pricing across other plan tiers, we made the decision to keep the Starter plan pricing unchanged. Since custom code usage on Starter accounts is extremely low, weâre redirecting that capability while increasing Flows transactions for all Starter users. Our goal is to provide alternative ways to extend functionality without raising your costs.
We understand this wonât work for everyone, and if custom code is critical to your workflow, please reach out and we can help you explore options that best fit your needs.
Thank you,
Kara
Thanks Kara
Yes, change naturally brings some apprehension (perhaps not entirely justified, I admit). Thank you for your response and for taking your clientsâ concerns into account.
Looking forward to whatâs next.